Timeline for Should I return an HTTP 400 (Bad Request) status if a parameter is syntactically correct, but violates a business rule?
Current License: CC BY-SA 3.0
25 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 13, 2024 at 17:36 | comment | added | GoFree | @MaximeRossini Well, HTTP is just one way of transfering data from one system to another. But there are many other ways to transfer those data. You could e.g. connect directly to remote database to transfer those data. Or you could be connecting over ssh directly to remote filesystem. The class that uses HTTP/db connection/ssh connection needs to know how to convert business object into HTTP/db/ssh request and how to process the response. But the business layer should not even know something like that is part of the system. | |
| Mar 12, 2024 at 16:31 | comment | added | Maxime Rossini | @GoFree I agree with your 1st message. I disagree with the rest. If you don't couple your business layer with HTTP, you can never decide what HTTP method to use for your endpoint (e.g. GET for reads). In a web application, HTTP is part of your business layer. Request methods and cache headers are part of the features that HTTP exposes to your business layer, and so do status codes. Having sayed that, I don't think I added anything new to my previous messages, so we will have to agree to disagree on that I think :) | |
| Mar 11, 2024 at 14:58 | comment | added | GoFree | @MaximeRossini Response of 400 Bad Request can mean e.g. that your Content-Type header is wrong. I.e. the HTTP "envelope" itself is bad. Then if you use the same 400 Bad Request to mean that e.g. email address sent in the body of the request is invalid, you're using one set of error codes to mean two different things. The recipient of the 400 Bad Request now has to understand and operate on two separate layers: 1. HTTP, 2. Your business layer. That's just bad design. | |
| Mar 11, 2024 at 14:50 | comment | added | GoFree | @MaximeRossini Yes, the first sentence says that. But the fact, that the url has a verb in it means, that the endpoint is not a REST but "api over HTTP"/"RPC over HTTP". Many times people say one thing, but the reality is different. REST is an extremely specific technique how to do something and vast majority of people claiming they have REST do not actually have it. Unfortunatelly :-( | |
| Feb 13, 2024 at 10:33 | comment | added | Maxime Rossini | TCP is managed by your network controller and in-between network equipments, so this layer is by design abstracted away from your application code (your controller could switch to UDP seamlessly). HTTP is partially managed by your application (client and server), you CANNOT abstract it away. You can only limit the set of features that you use (avoid non-200 status codes, non-POST verbs, optional headers...) in case there's an apocalypse, but then you only use HTTP because your browser forces you to do so, and lose 90% of its features (which you then need to reimplement). | |
| Feb 13, 2024 at 8:36 | comment | added | Maxime Rossini | About the fact that you should be able to replace HTTP with something else: I don't see the point. HTTP is the foundation for your application layer and for all world wide web applications to use. You're gaining functionality by integrating with its mechanisms rather than abstracting from it. However, HTTP statuses should not be the only level of error codes. Your client must distinguish an "email syntax validation" error from an "email already in use" error. But all these errors can be grouped under 4XX status codes, because they rely on client input. Just use a sub error code. | |
| Feb 13, 2024 at 8:35 | comment | added | Maxime Rossini | @GoFree About the OP not doing REST, this is the first sentance of the question: "I have a REST endpoint". | |
| Feb 11, 2024 at 19:11 | comment | added | GoFree | @MaximeRossini You're right, pigeons are more similar to TCP. But the idea remains, you can replace HTTP with something else. It should not affect your other application layers, e.g. business rules. | |
| Feb 11, 2024 at 19:05 | comment | added | GoFree | @MaximeRossini Author of the original question is not doing REST API, but something like "RPC over HTTP", therefore rules about REST are irrelevant. Let's imagine you're using HTTP codes for your business rules. Let's say you receive back HTTP code 400 - Bad Request. Now you have to decide if the request is bad because your HTTP was e.g. syntactically malformed, or you broke some business rules. You're using one code to represent two completely independent situations, therefore breaking the Single Responsibility Principle. | |
| Oct 27, 2023 at 8:52 | comment | added | gnasher729 | Authorisation isn’t business rules. | |
| May 17, 2023 at 14:19 | comment | added | Maxime Rossini | Also, HTTP is not the transport layer. TCP is. Pigeons can transport HTTP requests and responses (you can write them on paper, they are text!). HTTP lives in the same layer as your business: the application layer. HTTP is just a foundation for your business rules, but in a REST API you cannot abstract from it, your business relies on most of its features. | |
| May 17, 2023 at 13:46 | comment | added | Maxime Rossini | I disagree with this answer. REST APIs do use HTTP status codes for semantics, that's the whole point of it. It lets the business layer interact with the transport layer so that it can benefit from HTTP mechanisms (caching, discoverability, etc.). 4XX statuses would have very little usefulness otherwise. Oauth uses 400 statuses to describe business errors (invalid credentials). 403 errors are business errors (some business rule denies you access to this resource). Most API frameworks throw 4XX status codes on business rule violations by default (attribute validation failures in dotnet core). | |
| Nov 17, 2020 at 10:50 | comment | added | Jack Casas | I agree that if we follow the specification guidelines, this is the correct answer; However, in my opinion, the specification should be updated to include business logic errors. It's a real pain always having to parse the response and check if the request was successfull or not. | |
| Jan 15, 2020 at 15:20 | comment | added | Tony Cheetham | Just adding more weight to this, if the HTTP layer has no problem with the data then you shouldn't be sending a HTTP error to indicate an error. This causes huge problems when you're trying to debug errors, because you've used your 400 to validate your business logic, what code do you now use to validate your transport layer? | |
| Jul 31, 2019 at 10:42 | comment | added | Roland Kwee | Using 200-OK is especially logical if the application includes an "error" field in the response body to describe any business-level errors such as input value too high or too low or missing, product out of stock, etc. | |
| Jul 2, 2019 at 14:49 | comment | added | GoFree | Yes, you are correct to expect that the request succeeded. But on a Transportation Layer! Because HTTP status code is part of transportation protocol (as the acronym HTTP implies). Not on a Business Layer. A Post Office will not tell you if your tax return form inside the envelope is valid. It will only tell you if the address on the envelope is valid. Post Office deals with transportation of the envelope, just like HTTP, not with the content of the envelope. | |
| Jun 11, 2019 at 12:51 | comment | added | k0pernikus | If a server responds a 2XX, I expect the success case. Regardless of the type of error, request or server-side, I never expect the 2XX range but rather 4XX or 5XX. I have worked with api returning 200 OK for error cases, and it is a pain to parse them then. | |
| Feb 15, 2019 at 10:56 | comment | added | GoFree | @Thomas Lauria I haven't seen a proper implementation of RESTFUL API yet. However, REST API is a buzzword today so every company has to use it (the word, not the technology) without actually understanding the concept behind it. So yes, it's being used in a wrong way everywhere. What programmers usually create is not a REST API, but HTTP API, or API OVER HTTP. Actually one of the few good RESTFUL implementations is the HTTP itself :) | |
| Feb 14, 2019 at 7:27 | comment | added | Thomas Lauria | @GoFree This is a really good answer to rethink API Design. But isn't it the case, that we use HTTP and its response code as eminent part of the business rules layer when we use a REST API? | |
| Aug 30, 2017 at 14:27 | comment | added | Ewerton | Better explanation i seen so far. I have this same question and seems that all the word thinks differente from me and you @GoFree | |
| Mar 7, 2017 at 23:27 | comment | added | GoFree | Yes, returning 404 in that case is fine. I'm not saying that server should always send 200 OK with an explanation in the body. | |
| Mar 7, 2017 at 14:40 | history | edited | GoFree | CC BY-SA 3.0 |
Clarifying
|
| Mar 7, 2017 at 11:59 | review | Late answers | |||
| Mar 7, 2017 at 12:02 | |||||
| Mar 7, 2017 at 11:45 | review | First posts | |||
| Mar 8, 2017 at 10:22 | |||||
| Mar 7, 2017 at 11:43 | history | answered | GoFree | CC BY-SA 3.0 |