4 ms·

I think the author is aware and I noticed the term REST does not appear anywhere in the article. The main idea of the article is exactly that he does not agree

I think the author is aware and I noticed the term REST does not appear anywhere in the article. The main idea of the article is exactly that he does not agree that http error codes be used for application level errors (as REST principles recommend). I think at this point that ship has sailed. Most HTTP based API will use http error codes in various ways. I would be surprised to not receive a 404 when requesting a resource ID that does not exist for example when consuming a new API.

TimTheTinker 4y ago
> I think at this point that ship has sailed. If you were talking about TCP/IP, then perhaps - because much of the internet's infrastructure is hard-coded (even burned into silicon) to use current standards. But application semantics aren't frozen in stone by any means. Servers and clients built atop HTTP are still being written. Why not adopt better patterns that apply properly separate semantics for each layer? I liked the REST ideas when they came out, particularly because they provided a much better and simpler alternative to SOAP. But I think improving patterns where we can is always a good idea.
- smashed 4y ago
  Of course. Its just that in the general mindset, an hypothetical average dev who needs to call your API won't be surprised to receive a 404 for a missing resource. I might be wrong of course. Either way, a proper api doc/spec should make either approach a non-issue. Personnally, I've switched to graphql where it makes sense. Application level error codes and handled on the graphql layer, not on the HTTP layer, so you could say I've adopted that approach!