Consider return value when doing GET on non-existent table

[leondutoit]

When a client does a GET on an endpoint which does not yet exist, but theoretically could, the API returns a 404, currently with a JSON message in the HTTP body. There has been a request to return [] instead.

A bit unclear what it should be, given that it is a 404, options:

• no HTTP body at all
• []
• null

[f-krull]

https://mattermost.uio.no/uio-it/pl/gs8huq61wiy1pb1ayawn4mumyc

[leondutoit]

The API currently functions:

• similar to the way a filesystem does:

leoncd@leondutoit ~ % ls lol
ls: lol: No such file or directory
leoncd@leondutoit ~ % mkdir lol && touch lol/cat
leoncd@leondutoit ~ % ls lol
cat
leoncd@leondutoit ~ % rm lol/cat
leoncd@leondutoit ~ % ls lol
leoncd@leondutoit ~ %

• similar to the way a database does:

leoncd@leondutoit ~ % psql -U tsd_backend_utv_user -d tsd_idp
psql (14.8 (Homebrew))
Type "help" for help.

tsd_idp=> select * from lol;
ERROR:  relation "lol" does not exist
LINE 1: select * from lol;
                      ^
tsd_idp=> create table lol(x int); insert into lol values (1);
CREATE TABLE
INSERT 0 1
tsd_idp=> select * from lol;
 x
---
 1
(1 row)

tsd_idp=> delete from lol;
DELETE 1
tsd_idp=> select * from lol;
 x
---
(0 rows)

The main difference is that mkidr, and create table are not implemented as separate API calls. One could imagine PUT /endpoint without a body would be an appropriate implementation, if needed.

Returning to the discussion, I think the current behaviour is fine, since it matches what you typically experience with other data storage interfaces. If we're going to change the behaviour of doing a GET /endpoint when the endpoint in question does not exist, then I favour returning 404 with no body at all, but not [].

[f-krull]

With 404, the body is fine as it is. No need to change.

[f-krull]

The main difference is that mkidr, and create table are not implemented as separate API calls.

Exactly. I guess the creation of the "container" works transparently under the hood to make it easier for clients to put stuff into it. It would be consistent to have the same transparency when listing the content of the container. Currently, every single implementation of a client has to handle the case "nothing there yet".

Anyway if 200 + [] comes with downsides, no big deal - let's keep it as it is.