4 ms·

I agree - though I also agree with the author that this is an area where REST specifications are a little clunky. Yes, `api/v1/employees/100` should return a 4

I agree - though I also agree with the author that this is an area where REST specifications are a little clunky. Yes, `api/v1/employees/100` should return a 404, because that path represents the location of a specific entity and that entity does not exist. Just as the author thinks it's clunky to return HTTP error codes representing application errors, I think it's clunky to apply application logic to HTTP method semantics. GET, POST, and DELETE were designed as instructions telling a web server how to handle static-ish content, and it shows in their design. Why would a GET have a body? It's a request for the server to return a specific file. This leads to breaking REST standards - for example, search endpoints that logically are GET calls (they return entities), but are implemented as POST methods because the search criteria is complex enough that you wanted a request body. Or bulk delete calls that are similarly implemented as POST methods. REST works best in a "rules are meant to be broken" manner in my opinion. It's not a bad system (which is why it is so common), but mixing application logic with HTTP transport logic does lead to oddities.

bachmitre 4y ago
this
dvlsg 4y ago
Some applications opted for using GET with request bodies as well, for better or worse. Elasticsearch comes to mind. There have been some attempts to extend the list of http verbs to include something that fits those use cases more naturally - SEARCH and QUERY. QUERY got more traction, if I remember correctly, but I haven't heard much about it in a while. https://www.w3.org/2012/ldp/wiki/Proposal_for_HTTP_QUERY_Verb https://www.w3.org/2012/ldp/wiki/Proposal_for_HTTP_QUERY_Ver...
- ognarb 4y ago
  SEARCH is used by the WebDAV standard, not that I like WebDAV search syntax https://gist.github.com/CarlSchwan/66fde29d52022c0ef76aec362c01a846 https://gist.github.com/CarlSchwan/66fde29d52022c0ef76aec362...
  - dragonwriter 4y ago
    > SEARCH is used by the WebDAV standard That’s probably part of the reason the more general one proposed for HTTP is “QUERY” and not “SEARCH”. Also, WebDAV, in following its apparent design philosophy of “more is more”, has multiple different GET-with-(required or optional)-body methods with different purposes: PROPFIND and REPORT as well as SEARCH.
  - yencabulator 4y ago
    You might like QUERY: https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-meth...
rglullis 4y ago
If you have POST for search and bulk delete, you are "doing REST wrong" and calling RPC by another name.
- gnutrino 4y ago
  Not true.
  - rglullis 4y ago
    The "doing REST wrong" was in quotes to express that the practice might be widely accepted but it is not exactly kosher. In "true" REST, if you have a "search" endpoint, POSTing to it should create to a resource, which could be a reference to the list of results. The created resource should have its own endpoint (something like `/search/results/:query_id`), and the client could then cache it. If you don't want to do that, but still want to say you are really following REST, you could have an endpoint to represent your resources (`/products`) and use GET with filter parameters in the query string (`/products?search=my+search+term`)
treis 4y ago
>Yes, `api/v1/employees/100` should return a 404, because that path represents the location of a specific entity and that entity does not exist. A GET request to that path should return the current state of the resource at the path. As you note, the current state of that entity is that it does not exist. Let's look at the spec: >200 OK - The request has succeeded. The information returned with the response is dependent on the method used in the request, for example: > GET an entity corresponding to the requested resource is sent in the response; Did the request succeed? Yes, we found the current state of the entity so we return 200 What do we return? "An entity corresponding to the requested resource". In this case however we want to represent an entity that doesn't exist.
- dragonwriter 4y ago
  > A GET request to that path should return the current state of the resource at the path There is no resource at the path. > As you note, the current state of that entity is that it does not exist. A thing which does not exist does not have state. Existence (and even moreso non-existence) isn’t a state, existence is logically presupposed in any description of state.
  - treis 4y ago
    >existence is logically presupposed in any description of state Then please explain how you can write and I can understand the phrase "A thing which does not exist".
    - dragonwriter 4y ago
      Its convenient linguistic shorthand for a common case which would be more properly be described as “a concept of a thing which does not correspond to any actual thing”. While the equivalent linguistic shorthand has been present in most languages for quite a long time, the recognition that the confusion it can sometimes produce between concepts and concrete things is a category error is, while not nearly as old, also fairly old; it is central to Kant’s argument against the ontological argument for God’s existence, for instance.

bachmitre 4y ago

this

dvlsg 4y ago

Some applications opted for using GET with request bodies as well, for better or worse. Elasticsearch comes to mind. There have been some attempts to extend the list of http verbs to include something that fits those use cases more naturally - SEARCH and QUERY. QUERY got more traction, if I remember correctly, but I haven't heard much about it in a while. https://www.w3.org/2012/ldp/wiki/Proposal_for_HTTP_QUERY_Verb https://www.w3.org/2012/ldp/wiki/Proposal_for_HTTP_QUERY_Ver...

ognarb 4y ago
SEARCH is used by the WebDAV standard, not that I like WebDAV search syntax https://gist.github.com/CarlSchwan/66fde29d52022c0ef76aec362c01a846 https://gist.github.com/CarlSchwan/66fde29d52022c0ef76aec362...
- dragonwriter 4y ago
  > SEARCH is used by the WebDAV standard That’s probably part of the reason the more general one proposed for HTTP is “QUERY” and not “SEARCH”. Also, WebDAV, in following its apparent design philosophy of “more is more”, has multiple different GET-with-(required or optional)-body methods with different purposes: PROPFIND and REPORT as well as SEARCH.
- yencabulator 4y ago
  You might like QUERY: https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-meth...

rglullis 4y ago

If you have POST for search and bulk delete, you are "doing REST wrong" and calling RPC by another name.

gnutrino 4y ago
Not true.
- rglullis 4y ago
  The "doing REST wrong" was in quotes to express that the practice might be widely accepted but it is not exactly kosher. In "true" REST, if you have a "search" endpoint, POSTing to it should create to a resource, which could be a reference to the list of results. The created resource should have its own endpoint (something like `/search/results/:query_id`), and the client could then cache it. If you don't want to do that, but still want to say you are really following REST, you could have an endpoint to represent your resources (`/products`) and use GET with filter parameters in the query string (`/products?search=my+search+term`)

treis 4y ago

>Yes, `api/v1/employees/100` should return a 404, because that path represents the location of a specific entity and that entity does not exist. A GET request to that path should return the current state of the resource at the path. As you note, the current state of that entity is that it does not exist. Let's look at the spec: >200 OK - The request has succeeded. The information returned with the response is dependent on the method used in the request, for example: > GET an entity corresponding to the requested resource is sent in the response; Did the request succeed? Yes, we found the current state of the entity so we return 200 What do we return? "An entity corresponding to the requested resource". In this case however we want to represent an entity that doesn't exist.

dragonwriter 4y ago
> A GET request to that path should return the current state of the resource at the path There is no resource at the path. > As you note, the current state of that entity is that it does not exist. A thing which does not exist does not have state. Existence (and even moreso non-existence) isn’t a state, existence is logically presupposed in any description of state.
- treis 4y ago
  >existence is logically presupposed in any description of state Then please explain how you can write and I can understand the phrase "A thing which does not exist".
  - dragonwriter 4y ago
    Its convenient linguistic shorthand for a common case which would be more properly be described as “a concept of a thing which does not correspond to any actual thing”. While the equivalent linguistic shorthand has been present in most languages for quite a long time, the recognition that the confusion it can sometimes produce between concepts and concrete things is a category error is, while not nearly as old, also fairly old; it is central to Kant’s argument against the ontological argument for God’s existence, for instance.