3 ms·

The author simply disagrees with the the HTTP RFC and a couple decades and many of thousands of implementors. There's nothing wrong with that, and many impleme

The author simply disagrees with the the HTTP RFC and a couple decades and many of thousands of implementors. There's nothing wrong with that, and many implementors and applications have certainly taken the tack the author suggests -- i.e. use HTTP strictly as a simple transport layer rather than a representation of application state -- GraphQL is a great example. But the rfc is pretty darn clear: "The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists." I can't find a reasonable interpretation of this that somehow means if the server can't find the document you asked for, you should still return 200.

intelijstupide 4y ago
The author doesn't disagree with the HTTP RFC at all. All the author disagrees with is mixing the http server layer and application client layer status codes in the same client response being given to users. The only argument anyone should be having here is if they believe their api should speak HTTP to their client or if their api should speak through HTTP to their client. Personally? I think trying to shove business level response logic in HTTP (or REST for that matter) to be monkey butt level stupidity. HTTP was built as a RESTful protocol to serving files up to web browsers. And it works great for that. However, it was not designed to handle the 25 unique and user-readable or not-user-readable errors my one /authenticate route can throw back at the user at different times. REST and HTTP by extension excels at simple CRUD or file serving operations. But it's just not suitable for these kinds of API's. Here's an example: If my HTTP speaking API needs to respond with an error, how should my client handle it? How should I differentiate errors that should be displayed to users and errors that should be used only for debugging? If you need to suggest that my client needs to parse out the errors or differentiate between server and api errors in order to be able to show these errors to users then you've sort of proved my point that HTTP isn't a suitable solution to this problem - you're already wrapping an extra non-HTTP protocol inside HTTP, you're just only doing it for errors instead of all application responses.

intelijstupide 4y ago

The author doesn't disagree with the HTTP RFC at all. All the author disagrees with is mixing the http server layer and application client layer status codes in the same client response being given to users. The only argument anyone should be having here is if they believe their api should speak HTTP to their client or if their api should speak through HTTP to their client. Personally? I think trying to shove business level response logic in HTTP (or REST for that matter) to be monkey butt level stupidity. HTTP was built as a RESTful protocol to serving files up to web browsers. And it works great for that. However, it was not designed to handle the 25 unique and user-readable or not-user-readable errors my one /authenticate route can throw back at the user at different times. REST and HTTP by extension excels at simple CRUD or file serving operations. But it's just not suitable for these kinds of API's. Here's an example: If my HTTP speaking API needs to respond with an error, how should my client handle it? How should I differentiate errors that should be displayed to users and errors that should be used only for debugging? If you need to suggest that my client needs to parse out the errors or differentiate between server and api errors in order to be able to show these errors to users then you've sort of proved my point that HTTP isn't a suitable solution to this problem - you're already wrapping an extra non-HTTP protocol inside HTTP, you're just only doing it for errors instead of all application responses.