The Iceberg REST Catalog specification defines a consistent, engine-neutral HTTP API for catalog operations. It decouples query engines and applications from catalog implementations, allowing different engines, languages, and catalog services to interoperate without vendor-specific client libraries. section 7.3 section 7.3.2
Before the specification, catalog logic and transactional behavior lived largely in language-specific clients. Divergent implementations could cause incomplete feature support, conflict-detection errors, lost updates, inconsistent table state, and silent correctness bugs. section 7.3.1
The specification standardizes and centralizes several responsibilities:
- Defines operations for retrieving table metadata, listing namespaces, registering tables, and committing changes. section 7.3.2
- Moves transactional responsibility, conflict resolution, and increasingly scan planning from individual engines into the catalog service. section 7.3.2
- Reduces the need for catalog providers to maintain separate Java, Python, Go, and Rust client libraries. section 7.3.1 section 7.3.2
- Creates a consistent location for access control, policy enforcement, governance, and metadata coordination. section 7.3.2 section 4.3.3
Choosing REST compatibility
A regulated enterprise running Spark, Trino, and Flink across regions and cloud providers can evaluate Apache Gravitino, Lakekeeper, and Nessie against requirements for open APIs, auditing, federated metadata, and multi-engine access. REST compatibility supports a unified governance model, but each engine’s read and write support still requires verification. section 7.5.3 section 4.3.3
Figure 7.7 Using the REST Catalog specification, a client written in any language can talk to all catalogs, regardless of what language the catalog server is written in, improving interoperability.
Use the interoperability diagram to see how a client written in one language can communicate with catalog servers implemented in different languages. section 7.3
