3 ms·

> 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 (eve

> 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!