apache / apache/iceberg

Expose server-assigned resource identifiers (tableId) in LoadTableResponse REST API

Open
#16,399 0 comments 0 reactions 0 assignees View on GitHub
proposal
Dominant language
Java
Stars
9.2k
Forks
3.5k
Avg merge
2d 16h
Merged PRs (30d)
129

Description

### Proposed Change

## Proposed Change

### Summary

Expose server-assigned resource identifiers (e.g., `tableId`) in the loadTable REST response so that clients can use them for resource-level access control without HTTP-layer interception.

### Motivation

When a REST catalog backend assigns server-side identifiers to tables (e.g., S3 Tables assigns a `tableId` used in ARN construction), downstream systems that federate through the Iceberg REST protocol need this identifier for credential vending. Specifically, they need it to construct resource-level IAM policies with table-scoped ARNs.

Today, the `tableId` is present in the raw HTTP response body but is not surfaced through the RESTCatalog client API. The only way to access it is to wrap the HTTP client and intercept responses before deserialization. This is brittle and breaks across Iceberg library version bumps.

### Proposed Change

Include server-provided resource identifiers (such as `tableId`) in the `config` map of the `LoadTableResponse`, or introduce a dedicated field in the response schema for backend-assigned metadata. This would allow REST catalog clients to access the value through the standard API contract without HTTP-layer interception.

### Use Case

Apache Polaris (apache/polaris#4052) federates to S3 Tables REST endpoints and needs the `tableId` to construct `arn:aws:s3tables:::table/{tableId}` ARNs for scoped IAM session policies during credential vending. Currently worked around via a `ConfigCapturingHTTPClient` wrapper that intercepts the raw response.

### Proposal document

_No response_

### Specifications

- [ ] Table
- [ ] View
- [x] REST
- [ ] Puffin
- [ ] Encryption
- [ ] Other

Contributor guide

Open the contributing guide

Research direction

Start with RESTCatalog's loadTable response handling and the LoadTableResponse schema, then compare the raw REST response fields with what the client API exposes. Resolve whether backend-assigned identifiers belong in the config map or a dedicated response field, and verify that tableId is available through the standard client API without HTTP interception.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, java
Domain
api, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.