Hi Adnan, Thanks for bringing this topic to our attention.
In general, for operations creating new resources, the event instrumentation logic could rely on the incoming request. E.g. for createCatalog, if the response does not contain the catalog resource, it is generally OK to grab it from the incoming CreateCatalogRequest object. There could be settings set by the server that are not present in the original request though. Therefore, I think that the proposed changes generally make sense. Regarding addGrantToCatalogRole and revokeGrantFromCatalogRole: it would be beneficial to the discussion if we could have a clear picture of what the response would be like. For instance, would it be possible to reuse the GrantResource object [1] ? I think it contains all the required information, including the privilege details. Thanks, Alex [1]: https://github.com/apache/polaris/blob/327697c78e26a0c89ce72d87cbe6913c5b3c30fd/spec/polaris-management-service.yml#L1633-L1653 On Sat, Sep 6, 2025 at 12:04 AM Adnan Hemani <[email protected]> wrote: > > Hi all, > > While instrumenting event generation for all APIs, I found multiple public > APIs which I would like to request a change to in order to better support > event instrumentation as little-to-no cost to performance and/or bytes sent > in a response. > > createCatalog > > This API currently returns (on a successful call): > Status: 201 CREATED > Body: Empty > I’d like to propose for it to return the following: > Status: 201 CREATED (no change) > Body: Catalog POJO > > I don’t see this as extremely controversial - unless there is some historical > reason for not doing this. RFC 9110 > <https://datatracker.ietf.org/doc/html/rfc9110#name-201-created> also > recommends describing the resource created. > > createPrincipalRole > > This API currently returns (on a successful call): > Status: 201 CREATED > Body: Empty > I’d like to propose for it to return the following: > Status: 201 CREATED (no change) > Body: Principal Role POJO > > Same reasoning as above. > > createCatalogRole > > This API currently returns (on a successful call): > Status: 201 CREATED > Body: Empty > I’d like to propose for it to return the following: > Status: 201 CREATED (no change) > Body: Catalog Role POJO > > Same reasoning as above. > > addGrantToCatalogRole > > This API currently returns (on a successful call): > Status: 201 CREATED > Body: Empty > I’d like to propose for it to return the following: > Status: 201 CREATED (no change) > Body: A new POJO containing the following fields: > PolarisPrivilege POJO (this contains: securable PolarisEntityType, securable > PolarisEntitySubType (if applicable), and grantee PolarisEntityType (if > applicable)) > GrantResource POJO > > This is slightly more complicated, but I believe the proposed POJOs are still > attempting to describe the newly-added Grant that was applied to the Catalog > Role. > > revokeGrantFromCatalogRole > > This API currently returns (on a successful call): > Status: 201 CREATED > Body: Empty > I’d like to propose for it to return the following: > Status: 201 CREATED (no change) > Body: A new POJO containing the following fields: > PolarisPrivilege POJO (this contains: securable PolarisEntityType, securable > PolarisEntitySubType (if applicable), and grantee PolarisEntityType (if > applicable)) > GrantResource POJO > Cascade boolean - which states whether this revoke should cascade down. > > This is slightly more complicated, but I believe the proposed POJOs are still > attempting to describe the newly-revoked Grant that was removed from the > catalog role. > > Let us start discussion here first to flesh this out. If the thread does not > get any traction within a few days, then I will start a community vote for > making these changes. Thanks! > > Best, > Adnan Hemani >
