Reducing Partition Public API Surface: Transitioning to GET-Only Endpoints
Reducing Partition Public API Surface: Transitioning to GET-Only Endpoints
Status
-
Proposed -
Trialing -
Under review -
Approved -
Retired
Context & Scope
The Partition OpenAPI specification defines POST, PATCH, DELETE, and GET endpoints.
The Partition Service is responsible for creating and retrieving partition-specific properties, also known as tenant configurations. It can represent existing backend configurations, but the API does not provide a way to declare them. This means that if a partition configuration lacks corresponding resources on the backend, it will not be operable.
Since the Partition Service is the first point of configuration for the OSDU platform, it is not possible to reuse common internal authentication and authorization flows. The Partition Service must be deployed before any other component. Additionally, it is not feasible to use the Entitlements Service to authorize requests because Entitlements itself depends on the Partition Service to function.
While the Partition API is technically internally used by OSDU services to retrieve tenant configurations, only the GET endpoints serve this purpose. The POST, PATCH, and DELETE endpoints are not utilized by OSDU services and cannot serve as a standard implementation across all OSDU deployments. Any use of these endpoints would require corresponding backend changes.
This presents challenges in establishing a unified approach. As part of the transition to the One CI/CD Pipeline, the Community is developing acceptance tests to provide a standardized way to validate any OSDU platform and reduce inconsistencies.
During implementation, we encountered multiple tests that had to be ignored due to the lack of a common authentication flow, each provider implements authentication and authorization according to their requirements:
It's also not possible to create an end-to-end (E2E) acceptance test, as a simple POST request to create a tenant configuration is insufficient to actually create a partition. Additional steps, such as resource allocation and bootstrapping, are required. These low-level interactions are not supported by the OSDU API.
Decision
Reduce the Partition public API to only GET endpoints. Update the OpenAPI spec to remove all management endpoints (POST, DELETE, and PATCH), keeping only GET endpoints.
Update the acceptance and certification tests accordingly, removing validation for all endpoints except GET.
We do not propose changing the service code, except for marking the POST, DELETE, and PATCH endpoints as hidden to exclude them from the OpenAPI spec.
Rationale
With the current API, we may be giving platform users and client app developers the false impression that they can use the Partition service's POST, DELETE, and PATCH endpoints without actual access to the underlying resources.
The management endpoints of the Partition service conceal too many implementation-specific details, making it nearly impossible to consolidate them into a single approach.
We'll be able to create common tests based on GET API, that can be reused without tweaks.
A simplified OpenAPI spec could make it easier to improve Partition functionality. Some might even consider reimplementing it in a declarative way, where the GET tenant config reflects the actual state of the platform rather than just a record in a database.
Consequences
The POST, DELETE, and PATCH endpoints will be removed from the OpenAPI spec.
No changes will be made to the service code except for hiding these endpoints.
Tests will be updated to validate only GET endpoints.