Hi Dmitri, Yes, I saw the corresponding PR and commented on it.
I agree that this change would require moving to a V2 of the API since it is a breaking change. I'm just curious to see what the rest of the community thinks about this. Thanks, Regards JB On Mon, Dec 1, 2025 at 6:11 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi JB, > > There was a related discussion [1] in Sept. > > From my POV the change makes sense, but it's a kind of change that would > normally require moving to a v2 of the API... which is perfectly fine, it's > just a matter of handling (old) client expectations. > > [1] https://lists.apache.org/thread/bhd1srzks0pz0odoqmm87gfyj2yz2k41 > > Cheers, > Dmitri. > > On Mon, Dec 1, 2025 at 12:04 PM Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi folks, > > > > While testing Polaris 1.3.0-incubating release, I saw something "weird" > to > > me. > > > > In the Polaris Management API, we have several PUT operations: > > - updateCatalog > > - updatePrincipal > > - assignPrincipalRole > > - updatePrincipalRole > > - assignCatalogRoleToPrincipalRole > > - updateCatalogRole > > - addGrantToCatalogRole > > > > For me, assignPrincipalRole, assignCatalogRoleToPrincipalRole, > > and addGrantToCatalogRole operations are confusing: > > - in REST, PUT means a resource update. However, these operations return > > 201 Created (e.g. the request has been fulfilled, resulting in the > creation > > of a new resource). Imho, 201 is not accurate here, it should return 204 > No > > Content (the server successfully processed the request, and is not > > returning any content). > > - For these operations, if we consider that they should return 201 > Created, > > then, imho, it should not be PUT operations but POST operations > > (considering creation of resource). > > > > These "assignment" operations can be considered as updates on resources, > so > > PUT makes sense to me, meaning that they should return 204 (not 201). > > > > Thoughts ? > > > > Regards > > JB > > >
