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