5 ms·

I’m not sure what the infatuation with HTTP verbs is. RPC allows modeling objects and arbitrary verbs. REST gives you a handful of verbs and punts on data model

I’m not sure what the infatuation with HTTP verbs is. RPC allows modeling objects and arbitrary verbs. REST gives you a handful of verbs and punts on data modeling. It always seemed like a step back from an API design perspective. Definitely a battle I lost but never really understood the other side to begin with.

AtlasBarfed 4y ago
Standardization and a common language. Limits. Well developed error codes. Rpc is a huge footgun. What's annoying about rest is that it is a religion treated as a universal truth. But really, rest is basically crud.
- eastbound 4y ago
  However, anyone who has used HTTP error codes in REST knows to avoid that – Receiving a 404-Not-Found causes hours of debugging and blind poking compared to receiving a 200-OK-{“error”:”Entity not found”}…
  - bigDinosaur 4y ago
    Why can't you do a 404 + message?
    - charrondev 4y ago
      Yeah that seems the obvious thing. Our 404s say what wasn’t found (a resource; the endpoint, some associated data in the request). Our 403s describe what permissions precisely the user is missing. Our 400s describe what is malformed about the request.
    - mappu 4y ago
      HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.
      - bigDinosaur 4y ago
        This is absolutely counter to everything HTTP is supposed to be used for. I'm not quite sure how to even respond.
        vrnvu 4y ago
        It's a common discussion with HTTP Status Codes. Application vs Transport layer. HTTP status are a mix of both and it can be misleading. A couple of weeks ago there was an interesting post about this topic here in HN.
      - ahtihn 4y ago
        If you serve static content with nginx or any other webserver, you'll get 404 for any file that doesn't exist. Why should '${my_widget} not found' be different?
        number6 4y ago
        The Webserver Servers a file or an endpoint. This file or endpoint have indeed be found. On this layer the transaction was successful. So if you return 404 on this layer you are saying that whatever file or endpoint you searched is not there. If you ask for a resource at an endpoint that does not exist e.g. via an parameter in the url and return 404 it is not clear if the endpoint does not exist e.g. the endpoint.php is missing or the resource you are looking for. Leading to questions like: is the endpoint down, is my internet wonky, did I misspell the name, and business logic related questions: is there no such widget, is the widget out of stock, should I call another endpoint? 404 does not indicate non existence but it indicates an inability to be found by the server. It's a nuance and it only matters when it does and then it bites...
        ahtihn 4y ago
        You're talking about implementation details on thw server side. Why should the client care about that? Why should the error code for /product/foo/thumbnails/123.jpg be different if served with nginx serving a static file or an application server that dynamically generates it based on the product id?
- moring 4y ago
  I disagree about well-developed error codes. Examples: * There is no useful distinction between different kindes of bad requests (syntactically wrong, structurally wrong, not applicable to the data found, etc.) * Special handling is needed to test if a resource exists -- you cannot just GET it and check for a 404 code because browsers log all 404 as errors, even if it's the "happy path" * The error codes confuse authentication and authorization These error codes are useful when there are middle-men (e.g. proxies) that can understand them without having any application-level logic. But for most REST APIs you don't want those in the way, so that point is moot. My (to be evaluated) opinion is that RPC is underrated because there have been horrible RPC monstrosities in the past, though I'm aware that without any well-done RPC this opinion is useless.
  - klodolph 4y ago
    The way I think of the status codes is as instructions for how a generic HTTP client or proxy should or may behave in response. Any status code which, in practice, does not affect generic client behavior, does not need to be distinguished in the status code (and can instead be distinguished in the body of the response). For example, status 412 can be thought of as "try the transaction over again, your information about the resource is out of date". Maybe your client has generic support for atomic operations on resources, and 412 controls that. 429 can be thought of as "slow down". If your client has built-in throttling, 429 controls that. > There is no useful distinction between different kindes of bad requests (syntactically wrong, structurally wrong, not applicable to the data found, etc.) In general, a bad request is not something that client software would be expected to handle, other than "don't expect a different result if you try again". Obviously this is not a hard and fast rule because some errors are truly transient and some servers give the wrong error code due to bugs or whatever. You could go all WebDAV with status 422 for non-syntactic errors, but I am skeptical of its utility. If your action is not applicable to the resource, you have 405. When there's a 400 error, the expected client response is "some programmer will come by and look at the logs if it turns out to be a problem". > Special handling is needed to test if a resource exists -- you cannot just GET it and check for a 404 code because browsers log all 404 as errors, even if it's the "happy path" This is more of a UX issue with the browser console than any problem with HTTP. > The error codes confuse authentication and authorization Eh, it could be worse. We also have misspelled headers like "referer". As long as clients and semantics use the correct semantics, I don't care.
irrational 4y ago
Yes, people who use put and delete (and any other verb other than post and get) come off as insufferable bores to me. Heck, you just use GET and it will work fine 99% of the time.
- andybak 4y ago
  And that 1% is a killer. Ask the people who had content deleted because of a GET API and bad interactions with pre-fetching and caching.
- robertlagrant 4y ago
  Having GET commonly understood as idempotent is ergonomic.
  - jcelerier 4y ago
    everything that relies on a "common understanding" from humans or ridiculous things like non-compiler-enforced idioms, programming styles, etc. is bound to fail at some point. the only thing that matters is what the PL / system accepts.
    - robertlagrant 4y ago
      Do you think that browsers pre-emptively executing GET requests, or proxies caching GET responses, is a common understanding from humans?
      - jcelerier 4y ago
        Those are just bugs from engineers who assumed that such a common understanding existed. Bug reports should be filled, that's all.
- Sohcahtoa82 4y ago
  "GET" should not be used for anything that changes state (beyond simple logging of requests). I'm an AppSec engineer and if I were doing a penetration test and found that an endpoint was using GET requests for state changes, I'd consider it a serious enough bug to put it on the report, even if it wasn't a security issue.
afiori 4y ago
Most people are doing RPC-on-HTTP and call it REST, probably for the better in many ways. I personally believe that the Verb/Noun/Resource part of rest is perfectly avoidable, while I believe that including URLs/URLs fragment/URLs-like object in responses is good. HTTP is a very complex message passing transport layer, API should separately use the platform (HTTP caches/proxies/verbs/headers) and its main messaging feature (URL + body); so just set the right headers and verbs (GET/POST are enough) and pipe JSON/whatever around (obviously this is for APIs, websites need to use the WWW/HTTP/HTML platform, not just the HTTP platform)
layer8 4y ago
HTTP verbs allow to leverage existing HTTP mechanisms like caching proxies and content-type negotiation.
samus 4y ago
HTTP verbs are best understood as describing the style of interaction with the resource: - GET/HEAD: read-only, cacheable - POST: side-effects, can be repeated, but not idempotent - DELETE: destructive side-effects, idempotent, no real response - PUT: creative side-effects, idempotent, can return the new resource

AtlasBarfed 4y ago

Standardization and a common language. Limits. Well developed error codes. Rpc is a huge footgun. What's annoying about rest is that it is a religion treated as a universal truth. But really, rest is basically crud.

eastbound 4y ago
However, anyone who has used HTTP error codes in REST knows to avoid that – Receiving a 404-Not-Found causes hours of debugging and blind poking compared to receiving a 200-OK-{“error”:”Entity not found”}…
- bigDinosaur 4y ago
  Why can't you do a 404 + message?
  - charrondev 4y ago
    Yeah that seems the obvious thing. Our 404s say what wasn’t found (a resource; the endpoint, some associated data in the request). Our 403s describe what permissions precisely the user is missing. Our 400s describe what is malformed about the request.
  - mappu 4y ago
    HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate. A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.
    - bigDinosaur 4y ago
      This is absolutely counter to everything HTTP is supposed to be used for. I'm not quite sure how to even respond.
      - vrnvu 4y ago
        It's a common discussion with HTTP Status Codes. Application vs Transport layer. HTTP status are a mix of both and it can be misleading. A couple of weeks ago there was an interesting post about this topic here in HN.
    - ahtihn 4y ago
      If you serve static content with nginx or any other webserver, you'll get 404 for any file that doesn't exist. Why should '${my_widget} not found' be different?
      - number6 4y ago
        The Webserver Servers a file or an endpoint. This file or endpoint have indeed be found. On this layer the transaction was successful. So if you return 404 on this layer you are saying that whatever file or endpoint you searched is not there. If you ask for a resource at an endpoint that does not exist e.g. via an parameter in the url and return 404 it is not clear if the endpoint does not exist e.g. the endpoint.php is missing or the resource you are looking for. Leading to questions like: is the endpoint down, is my internet wonky, did I misspell the name, and business logic related questions: is there no such widget, is the widget out of stock, should I call another endpoint? 404 does not indicate non existence but it indicates an inability to be found by the server. It's a nuance and it only matters when it does and then it bites...
        ahtihn 4y ago
        You're talking about implementation details on thw server side. Why should the client care about that? Why should the error code for /product/foo/thumbnails/123.jpg be different if served with nginx serving a static file or an application server that dynamically generates it based on the product id?
moring 4y ago
I disagree about well-developed error codes. Examples: * There is no useful distinction between different kindes of bad requests (syntactically wrong, structurally wrong, not applicable to the data found, etc.) * Special handling is needed to test if a resource exists -- you cannot just GET it and check for a 404 code because browsers log all 404 as errors, even if it's the "happy path" * The error codes confuse authentication and authorization These error codes are useful when there are middle-men (e.g. proxies) that can understand them without having any application-level logic. But for most REST APIs you don't want those in the way, so that point is moot. My (to be evaluated) opinion is that RPC is underrated because there have been horrible RPC monstrosities in the past, though I'm aware that without any well-done RPC this opinion is useless.
- klodolph 4y ago
  The way I think of the status codes is as instructions for how a generic HTTP client or proxy should or may behave in response. Any status code which, in practice, does not affect generic client behavior, does not need to be distinguished in the status code (and can instead be distinguished in the body of the response). For example, status 412 can be thought of as "try the transaction over again, your information about the resource is out of date". Maybe your client has generic support for atomic operations on resources, and 412 controls that. 429 can be thought of as "slow down". If your client has built-in throttling, 429 controls that. > There is no useful distinction between different kindes of bad requests (syntactically wrong, structurally wrong, not applicable to the data found, etc.) In general, a bad request is not something that client software would be expected to handle, other than "don't expect a different result if you try again". Obviously this is not a hard and fast rule because some errors are truly transient and some servers give the wrong error code due to bugs or whatever. You could go all WebDAV with status 422 for non-syntactic errors, but I am skeptical of its utility. If your action is not applicable to the resource, you have 405. When there's a 400 error, the expected client response is "some programmer will come by and look at the logs if it turns out to be a problem". > Special handling is needed to test if a resource exists -- you cannot just GET it and check for a 404 code because browsers log all 404 as errors, even if it's the "happy path" This is more of a UX issue with the browser console than any problem with HTTP. > The error codes confuse authentication and authorization Eh, it could be worse. We also have misspelled headers like "referer". As long as clients and semantics use the correct semantics, I don't care.

irrational 4y ago

Yes, people who use put and delete (and any other verb other than post and get) come off as insufferable bores to me. Heck, you just use GET and it will work fine 99% of the time.

andybak 4y ago
And that 1% is a killer. Ask the people who had content deleted because of a GET API and bad interactions with pre-fetching and caching.
robertlagrant 4y ago
Having GET commonly understood as idempotent is ergonomic.
- jcelerier 4y ago
  everything that relies on a "common understanding" from humans or ridiculous things like non-compiler-enforced idioms, programming styles, etc. is bound to fail at some point. the only thing that matters is what the PL / system accepts.
  - robertlagrant 4y ago
    Do you think that browsers pre-emptively executing GET requests, or proxies caching GET responses, is a common understanding from humans?
    - jcelerier 4y ago
      Those are just bugs from engineers who assumed that such a common understanding existed. Bug reports should be filled, that's all.
Sohcahtoa82 4y ago
"GET" should not be used for anything that changes state (beyond simple logging of requests). I'm an AppSec engineer and if I were doing a penetration test and found that an endpoint was using GET requests for state changes, I'd consider it a serious enough bug to put it on the report, even if it wasn't a security issue.

afiori 4y ago

Most people are doing RPC-on-HTTP and call it REST, probably for the better in many ways. I personally believe that the Verb/Noun/Resource part of rest is perfectly avoidable, while I believe that including URLs/URLs fragment/URLs-like object in responses is good. HTTP is a very complex message passing transport layer, API should separately use the platform (HTTP caches/proxies/verbs/headers) and its main messaging feature (URL + body); so just set the right headers and verbs (GET/POST are enough) and pipe JSON/whatever around (obviously this is for APIs, websites need to use the WWW/HTTP/HTML platform, not just the HTTP platform)

layer8 4y ago

HTTP verbs allow to leverage existing HTTP mechanisms like caching proxies and content-type negotiation.

samus 4y ago

HTTP verbs are best understood as describing the style of interaction with the resource: - GET/HEAD: read-only, cacheable - POST: side-effects, can be repeated, but not idempotent - DELETE: destructive side-effects, idempotent, no real response - PUT: creative side-effects, idempotent, can return the new resource