Closed oleaasbo closed 9 months ago
Hi @oleaasbo
The newly created resource's ID is actually included in the response, but it's not in the response body. Instead, it's provided in the Location
header of the HTTP response. This approach aligns with common RESTful API practices and is used in many APIs, including Keycloak.
For example:
HTTP/1.1 201 Created
Location: http://localhost:32831/realms/multi-tenant/tenants/f1a8ad96-275d-47d1-a3e9-74832288f79a/invitations/22ff4fee-0bd8-493e-b3bd-4db331572d12
I see. I did not think to check the headers. My bad! I was unable to find any mentioning of this in the API docs. Even though this is common practice I feel this should be explained better in the API docs. I have implemented a lot of APIs before and somehow I have not yet been made aware of this practice. Thank you for sharing knowledge!
No problem at all. The entire Keycloak REST API works like this, which is why I haven't explicitly mentioned this in the documentation. Feel free to ask if you have any more questions!
When creating new resources through the API the response only contains http status 201 (Created) I would like to suggest to add the new resource's ID to the response. When using the API in a chained process there is an extra call to Keycloak needed that in my opinion should not be necessary Imagine the following scenario: (javascript)
This would be the preferred way to use the API but because the new Tenant ID is not present in the response we have to do an additional call to Keycloak to chain code that depends on the new tenantId
When including the id in the response the calls to Keycloak gets reduces by 50%