Improve INSERT and UPDATE response bodies for REST APIs

Feature request

Return meaningful response bodies for successful INSERT and UPDATE queries on REST API calls POST and PATCH.

Is your feature request related to a problem? Please describe.

Successful POST and PATCH HTTP requests will return an empty ({ }) response body giving no useful informations. Even though this could be considered as OK (everything is OK as far as it is not an error), the response body could instead be used to give meaningful information about the request result. This feature could improve the usability of Database REST APIs themselves, considering the case where a table consists of one (or more) auto generated values, or just a single autogenerated value as primary key, instead of being explicitely provided (90% of the cases could end up in a violation of the unique constraint).

Considering the “Todo List” example, the main todos table consists of a structure such as the follwing:

🔑 id	user_id	task	is_complete	inserted_at

Assume a POST request to insert a new row in a newly created databse, giving the following body:

{ "user_id": "{user.id}", "task": "{task}", "is_complete":"false" }

will eventually end up adding the row to the database with an auto generated id (primary key) and a inserted_at correspnding to the server insertion time, that may differ from the client issued one. Server side, we could end up having something like this:

🔑 id	user_id	task	is_complete	inserted_at
1	{user.id}	{task}	false	yyyy-mm-dd…

Client side, the response will just consist of a { } body, giving no information about id and inserted_at values.

For sure we could anyway build up our environment client-side expecting to follow a sequencial structure… with two additional insertions, we could end up in something like (extract):

🔑 id
1
2
3

Upon 3rd insertion, let’s now DELETE it.

🔑 id
1
2

And let’s add a new one, again. Server side:

🔑 id
1
2
4

But if the client had not internal memory about what happened (ex. the client disconnects after the 3rd row deletion), with a previous GET and a sequential logic, its id should be:

int new_row_id = last_row_id + 1 (= 3, not 4)

which is an inconsistent orphan entity.

If the client was able in the first place to retrieve even just the genereted id value from a successful POST response, a callback logic could be applied in order to create client-side entities in more consistent way.

ex.

1. var new_entity_body = { "user_id":"{user.id}", "task":"{task}", "is_complete":false }
2. HTTPClient -> `POST` new_entity_body
3. var response = HTTPClient.response
4. add_entity(response.id, new_entity_body)

Describe the solution you’d like

The most used solution (generally speaking) is to give as the response body the whole row’s values:

{ "id":"{id}", "user_id":"{user_id}", ... }

Considering the ability to request multiple insertion with just one http request:

POST 
{ [ 
{"task":"task_1"}, 
{"task":"task_2"} 
] }

A response schema could be:

{ [
{row 1},
{row 2}
] }

To simplify the response, this could be shortened to contain only generated values and key values

{ [
{"id":"1"},
{"id":2"}
] }

Describe alternatives you’ve considered

• Making a GET request each time rows are added/updated could be avoided
• Using Realtime REST APIs won’t be necessary (thus they are not available)

Additional context

[fenix-hub]

Prefer: return=representation in Header works like a charm.

Thank you very much, at this point I think that this should just be documented for noobs like me 😃

I’ll update my code and demos for sure. By the way, you can find it here.

Thank you for your help!

[io-Karim-developer]

{ “hint”: null, “details”: null, “code”: “42501”, “message”: “new row violates row-level security policy for table "profiles"” } how i can solve this