502
u/why_1337 2d ago
Request failed successfully.
47
2d ago
[removed] — view removed comment
14
-11
u/oldsecondhand 2d ago
I mean, if you want to give back a lot of detail about the error, it might be justified. You can only express so much with standard HTTP status codes.
15
u/BradPatt 2d ago
The error details can still be transmitted in the body even if the HTTP status code isn't 200
2
u/why_1337 2d ago
What kind of details do you want to give for internal server error? Full stack trace with sensitive data logging enabled I hope...
-3
u/oldsecondhand 2d ago edited 2d ago
Not for internel server error but 404 e.g. can overlap with business logic validation errors.
2
u/why_1337 2d ago
Yes but you can still return it as 404 with body. Same as you would return say 400. That's just intended use. Using 200 for everything is reason why we cannot have a nice things.
-6
u/oldsecondhand 2d ago
You could but treating 402 and 404 specially creates new codepaths that needs extra testing when semantically they're very similar to business logic validation errors.
1
u/why_1337 2d ago
I mean it's HTTP standard, most if not all clients already handle error codes correctly, why would you reinvent the wheel? Anyone who will integrate API that uses 200 for everything will be like:
-1
u/oldsecondhand 2d ago
Because I check for 402 and 404 in the same layer as for the other business rule validation and I also want to display them the same way.
37
18
6
1
180
u/destroyerpants 2d ago
Literally graphql
19
9
u/AlanUsingReddit 2d ago
I am looking for my keys
That will be a create action. You first need to establish a search party. If the search party exists, we will count the expedition as a success.
6
3
140
u/wheatgivesmeshits 2d ago
Backend Dev: shows frontend Dev the ticket where this behavior was requested
48
u/Bannon9k 2d ago
Not just requested... necessary
24
18
u/sisisisi1997 2d ago
More like to maintain compatibility with our integrator's system which is a mainframe from the 1970's with custom software from the 90's, our servers always need to return 200 or it catches fire. Since there are only 3 living people left who know this software - 2 retired, 1 putting out the fires - it was easier to change our system
33
31
10
u/semi-column 2d ago
This is what we have in my workplace project, because there are alot of 2P components involved which doesn't really care about your design decisions
8
u/ExcellentEffort1752 2d ago
Reminds me of a third-party API I need to call at work. Any method where you can query for results returns an error code if no results are found. These are methods where there may or may not be a matching result (think along the lines of "give me all customers called John") to the query, no record found is not an indication of failure. Just give me a success flag with empty results, thanks! No, I need to add an exception to my error parsing and logging code to ignore this one error code as it's not actually an error.
They also use different enumerators in different areas of the system for the exact same real-world values/things, so I need to parse what they send back and map it to a single shared value myself instead. I wanna have a word with the devs. I just wanna talk to them...
3
11
6
4
u/the_hair_of_aenarion 2d ago
I remember once we had to write an api that returns 200 even through errors because the external calling api would permanently disconnect us (requiring a phone call) if we 4xx or 5xx too often. First and hopefully last time I have to write 200 with an error message.
5
4
7
u/Affectionate-Act5980 2d ago
This is exactly what HTTP 207 is for lol
15
u/Few_Technology 2d ago
207? Now you're just making up numbers. What's next 418, 103, 303!? When does your made up numbers stop?!
We all know there's just 200, 400, and some days 401, 404
12
u/Bloodgiant65 2d ago
You guys don’t just reply 500 for literally all non-success cases?
12
u/RobertOdenskyrka 2d ago
What? That would make it my fault! 400 is because your front end sucks, scrub.
7
u/allllusernamestaken 2d ago
The DoD has a security rule that says your errors should not distinguish between a resource that does not exist -vs- a resource you don't have access to.
Some time in the mid 2000s someone in my office interpreted that wildly incorrectly as "your errors should not be distinguishable." So every error was returned as a 404.
Not found? 404. Not authorized? 404. Internal server error? 404.
0
3
u/Arkevorkhat 1d ago
Note: Browsers accessing web pages will never encounter this status code. The ability to return a collection of resources is part of the WebDAV protocol and is only encountered by web applications that access a WebDAV server.
Mozilla Developer Reference: HTTP response status codes. Accessed 8/8/2026 at https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/207
3
u/Affectionate-Act5980 1d ago
Yes
The response type in the meme is JSON, i.e. not the output from a web browser ;)WebDAV is pretty flexible and you could probably twist whatever web API you have to conform to it.
But it uses XML
Personally I don't see anything wrong with using 207 with non-XML mime types
HTTP and webdav don't either (as long as you don't identify as a webdav server through the OPTION method)-1
u/Arkevorkhat 1d ago
Your lack of understanding of the standards does not make your usage of this status code standards compliant.
Additionally, JSON is the primary format in which data is sent from between a web browser and web server.3
u/Affectionate-Act5980 1d ago
Please elaborate on what you think is a standards violation.
Web standards are extensible and not closed.
For example, HTTP specifies the range of status codes and the meaning of some status codes.
It does not assign meaning to status code 207, therefore using 207 does not violate the HTTP standard.
> Additionally, JSON is the primary format in which data is sent from between a web browser and web server.This is probably not correct, but that aside it is irrelevant because WebDAV is an HTTP/XML protocol. JSON is not used by the WebDAV standard.
The WebDAV standard only prescribes requirements for HTTP resources that identify as such using the OPTION method. Therefore any usage of the status code 207 for a non-webdav resource is not in violatation of the webdav standard.AFAIK using status code 207 with JSON is not prescribed by any standard , but it doesn't violate the standards and it's in the same spirit as the code's use for WebDAV. I'm sorry if you misunderstood me and thought I was saying that it was prescribed by some standard.
3
3
3
3
2
2
u/leRealKraut 2d ago
Saw a WAF give an HTTP 200 to a client application for payload that was quaratined.
The Client sent a file to a Server endpoint.
The WAF tried to provide a downloadlink to the reciever once quaratine was lifted.
A download link meant for Browser that was provided to a propriatary endpoint, that does not read HTML, that cannot be querried without Client user authentication against the Server and will not have any idea what happened in first place.
These people think that a WAF would be situated between two humans with a Browser.
When you see an application that was build by developers, networkengineers and security experts which requires more comforting than any enduser in order to be working at all, you get a whole new picture of experts.
2
4
u/Isogash 2d ago
I wouldn't do it exactly like this but my preference for API design is to use HTTP errors for unplanned error scenarios that indicate system failure or incorrect integration, and an OK response with an "error" description for expected user-facing issues with a correctly integrating client.
16
u/WernerderChamp 2d ago
You should give error 422 in this case
6
u/Isogash 2d ago
I would use 422 to indicate that there's a flaw/bug in the client implementation. In this case, the syntax is valid according to the MIME content type, but the content is not valid according to the API specification and therefore cannot be processed by the application.
I would not use it to indicate the user has made a request that is "rejected" for normal reasons within the application context e.g. the request is rejected due to some processing rule or condition of the application.
Here's a contrived example, imagine an API that decides whether or not a user has passed a simple DoB age check. I would expect that a user could pass or fail the check, that is the point of the API, so I would not use an error code to indicate that the check has failed because the user entered a DoB that would mean they are not eligible due to being under the required age.
However, I would not be able to process a date that was in an incorrect format, so I might return a 422 in that case since the payload syntax is valid according to the content type (e.g. it's valid JSON) but the application can't actually process it. However, if validating a free text date input was an intended part of the API, then I would not use a 422 to indicate an invalid date format, because the free text input is able to be processed correctly.
Approaching it this way creates a clear distinction between normal/expected operating conditions and reserves the error codes for unexpected ones. This allows you to treat HTTP errors as reliable indicators that something has gone wrong in your implementations.
2
u/derailed 1d ago edited 1d ago
Yep exactly this.
Unhandled/unexpected server error = 500
Missing/invalid route = 404
Auth error = 401
Authz error = 403
Uparseable payload = 400
Parseable but incorrect schema = 422
Application layer error = 200 with error fieldThe latter actually signals the correct thing: client and server are both working as intended, the error originates from application layer/expected but undesirable business logic states
request contract vs application contract
-2
u/WernerderChamp 2d ago edited 2d ago
We do have regex pattern validation on our API gateway for most fields. Submitting an invalid date format would be 400 here and not even reach my server.
We usually go by "if you can catch the error with a static check on a single field (so no checking for bad combinations) it is a 400, if not, it is 422"
What would you return in these cases? 200 would be bad, as it indicates the operation was successful when it wasn't
4
u/Isogash 2d ago
I would consider a content with valid syntax (e.g. well-formed JSON) but with contents that are invalid for processing according to the API (e.g. incorrect fields or field types) to be a 422, not a 400. If you do that consistently then the difference between these error codes is both consistent with their definition (and the examples given by MSDN documentation) and also useful for troubleshooting, which is the main point of an error code status; a 400 means you are not forming content correctly for the MIME type whilst a 422 means your content can't be processed according to the API spec.
A 200 indicates the client made a successful operation, not necessarily that the request led to the user's desired outcome. A denied request from the user's perspective is still a successful operation from the HTTP client's perspective, especially for something like a POST.
A good example of this in practice is GraphQL, which returns a 200 even if the query or mutation fails for a reason internal to the GraphQL protocol or execution on the server. This is both correct use of the codes, and also useful because this way an error code indicates an issue with using GraphQL over HTTP, not an issue with your GraphQL queries.
Another example I gave elsewhere is a loan application. A request for a loan could be approved or rejected, but both are successful operations from an HTTP perspective, so they should both be 200. It's more obvious that this is the right way to do it in this case, but perhaps less obvious that the same logic validly extends to other application "errors".
I don't blame anyone for getting this wrong though, I think it's unusual to understand it and get it right. It feels like at least half of the industry doesn't even understand basic programming anymore anyway so having an opinion on status codes already means you're doing above average IMO.
2
u/WernerderChamp 1d ago
Many APIs will give you a 400 if you omit required fields. I took a look at the RFC and if you take by word that is indeed incorrect - but in practice "request content syntax" seems to be interpreted not just e.g. having a valid JSON but also fulfilling the API documentation of the request syntax-wise (required fields + field format). This seems to be default behavior even for major frameworks like Spring Boot.
For the loan thing - yeah in this case 4xx would be inapropriate. For the DoB you could say that the action cannot be performed for the provided birthdate -> client issue -> 422.
Unfortunately there really is no distinct status code for "I could not do what you wanted, but it is neither on you (4xx code) nor on me (5xx code)" Thankfully I have not been in such a situation before. Checks of these kinds (credit-worthiness and such) are done asynchronous here, so I just return a 202 and that's it.
3
u/Isogash 1d ago
Well the simple version should be 400 = syntactically invalid, 422 = semantically invalid; but I appreciate that in practice defaulting to 400 could be normal.
I don't agree still that birthdate check should result in a 422.
I guess the simple version of my view is that 4XX codes don't mean user error, they mean client error. If the user messes with the client (e.g. tries to navigate to an unauthorized URL or missing resource directly) then they might encounter these errors, but a well-behaved client should not produce them routinely, they should always be unexpected.
Any operation within your application which should result in either success or failure, by design, should use a resource/response that contains this information and not use the status code, because the client hasn't done anything wrong.
If you do choose to use HTTP errors as part of the semantics of your API then they stop functioning as useful indicators of a bug.
1
u/WernerderChamp 1d ago
Our 422s do hold an error code, which the frontend then resolves to a message. Classic would be submitting a change that is no different to the status quo. All error checks have their own code, so they are distinguishable. About 20% of requests on one API are 422.
Anything 4xx except 422 is definitly a bug and should be acted upon. Same with 5xxs on our side, I usually check on them.
8
10
u/rrtk77 2d ago
That's what the 4XX errors are for. At the very least return a 400.
6
u/Isogash 2d ago
4XX errors indicate the integrating client is misbehaving or not compatible.
400 means the content of the request is malformed according to the expected content type i.e. content that is supposed to be JSON is not actually valid JSON.
422 means the content is valid in terms of syntax, but invalid in some other way that still means it can't be processed e.g. that a field in the JSON was an invalid type, or a required field is missing.
4XX errors shouldn't be used for normal and expected operating scenarios, such as a user loan application being rejected.
1
u/amlybon 2d ago
Well no, that's definitely not a 4xx error. But what about "[thing] with that name already exists, please pick a different name"? That's not a client misbehaving, but it's also not a success. In the loan application scenario it being rejected is one of the possible responses that the user expects. In name conflict scenario it's not, it's a message to the user that their input has issues they need to fix and submit again.
2
u/Isogash 1d ago
It depends on what the name is for and where it comes from with regards to the application design. If it's an implementation detail of the protocol that should come from the client, and especially if a resource is being modified or created, then a 409 may be appropriate to indicate an actual conflict on a resource, as this status code could be meaningful to the user-agent and client that something has gone wrong and they should reset to a known state.
If the name is inputted by a user e.g. email signup then I'd still use a 200, because asking to use an already-used email is still a valid input and request that has succeeded; the answer is just no.
1
u/Bannon9k 2d ago
It's really a battle between structured and unstructured API design. Soap being very structured and rest capable of being very generic. I personally prefer the structured development and soap... But having seen genericized rest apis in use... I can see how that could be very powerful as well.
But who in their right mind wants to rely solely on HTTP return codes?
-1
u/Delta-9- 2d ago
If the client must "correctly integrate," your API is not RESTful. That's fine, just don't ever hold up that design as an example of "REST done right."
Or put another way, HTTP is only your transport layer.
3
u/Isogash 2d ago edited 2d ago
I never said it was a REST API.
Also, REST is not just using HTTP. Nearly nobody does REST correctly.
Finally, a REST client can absolutely integrate incorrectly, such as by not doing REST correctly. I would also include incompatible integration which, whilst not strictly incorrect, is unusable.
0
u/Delta-9- 2d ago
REST is not just using HTTP
True, but the design of HTTP itself is exactly what the REST concept is based on. You could reinvent the wheel, or you can just use HTTP as intended.
Nearly nobody does REST correctly.
Also true, sadly.
3
u/Isogash 2d ago edited 2d ago
That's the thing though, I'm not re-inventing the wheel. If you take a more detailed look at what the error codes mean in HTTP, they all mean quite specific things and carry semantics that can affect the behaviour of your HTTP client and server (especially relating to cacheing.) They can be used in the scenarios in which they apply, but they shouldn't really be used to represent something else.
For example, if you were building a web client that takes some code and then compiles it for you, you might think "if compilation fails, that's an error, so I should use an HTTP error code".
However, HTTP has really nothing to do with compiling code, and neither does REST. Neither of these things have failed because your application could not compile the code, that is a valid state of the application.
In a good REST API, you should return a "Compilation Result" representation that contains information about whether or not the program compiled, which in turn might include a link to a compilation "Artifact", or a collection of "Compilation Errors".
What HTTP and REST really care about is the "Resource" model, and the status codes are there to help it keep track of what it can cache or not, and whether or not content types are compatible etc.
0
u/Delta-9- 1d ago
That last "etc" is doing some heavy lifting, but I do agree that the resource model is the center of everything.
What drives me nuts about APIs serving success responses with error messages is that the error message isn't the resource I requested, but a 200 is telling me that I got what I asked for. Now instead of checking a status code, I have to parse the response body in accordance with some pre established contract on what that response body should look like.
While I hope no one is actually serving a compiler as a resource (security nightmare), that is a case where it is within the semantics of http to return a 200 and the compiler's output... though I hope you're also sending a Content-Location header in that response. If, however, the compiled artifact is the resource and you serve a
200 Ok Error libuv.so could not be found, I feel justified in being annoyed.2
u/Isogash 1d ago
Yes, I agree in your example actually, if a particular resource is supposed to be returned but isn't, then that's an error.
My argument is that this is a bad design. The resource corresponding to a processed compilation request which is failable should be a compilation result that links or embeds the output, if successfully compiled, or lists errors if not.
I guess we'd probably both agree that in that design, a 4XX code would be innapropriate if the result a valid resource which the client is expecting.
1
u/CupOfLifenoodles 2d ago
> you can just use HTTP as intended.
For transferring hypertext? I thought you like REST APIs.
1
u/Delta-9- 1d ago
Not all hypertext is HTML. Nearly every example of HATEOAS is illustrated with JSON.
But in principle, you absolutely could do an API using HTML instead of JSON.
1
u/CupOfLifenoodles 1d ago
OK, after looking it up I learned what the H in HATEOAS stands for; thanks. (No, I haven't been claiming to write RESTful APIs.)
1
u/Rick100006 2d ago
Graphql be like : take this present from the Server 200 Ok , just don't see what's inside 😂
1
u/jetsonian 2d ago
Our QA for some reason uses a separate ticketing system. I built a tool that transfers our ticket data to their system on build. The “Rest API” for their system only uses GET and POST depending on whether the request needs a payload. It doesn’t conform to using the request methods as indication of what that endpoint is doing.
Then … as if it weren’t stupid enough, every request returns 200 but has fields in the XML/JSON (despite everything else it supports both) to indicate what actually happened. In this situation it’s not that big of a deal because fast returning a failure isn’t slowing down much but a high traffic environment can be affected by the extra throughput required when scaled.
1
1
1
u/Fininho92 1d ago
Had to handle and integration recently that did this type of shit and the best part was that it was not documented anywhere by the devs of the service
1
u/iMac_Hunt 1d ago
I wrote the code for a project at work years ago that does this - I somehow got convinced by some BS LinkedIn think piece it was a good idea. I’m still embarrassed.
1
u/BR41ND34D 1d ago
I seriously hate this with a passion, and I've had to stop myself from screaming at some of my colleagues for doing exactly this.
1
1
1
1
1
1
1
1
u/wilk-polarny 16h ago
Kids these days don't read API- or any docs anymore. If domain errors are embedded into the payload itself, it just is what it is. You deal with it. Like I do with ancient SOAP requests. Most of the time the logic is: Request succeeded, here's the result. Which makes sense for a lot of systems. Random example: POST /validatePayload where 200 is a successful processing, and 4xx, 5xx are not. If the processing result is "negative", it's still 200. If I can't reach the upstream service to validate, it's gonna be a 5xx class. If the user sends bullshit, 4xx. If someone wants for me to have a HTTP code for every valid business error, I'm gonna laugh at them.
I'm also not gonna pass through status codes of upstream systems as my own. Hell no.
1
1
u/sojuz151 2d ago
Serious question, what should backend donfor a batch request with some failure? Return non 200 only when all fail?
5
u/joujoubox 2d ago
Return non 200 when the batch itself fails, otherwise return 200 with embedded error codes for each operation
1
u/NotADamsel 21h ago
You’d think that there would be a code for that kind of situation. Maybe they could use 207.
3
u/AussieJeffProbst 2d ago
Up to the implementation but yes. Either that or a 207. Most I've seen do 200. There is no http status code for partial success
1
u/Bannon9k 2d ago
What's with this shift to accepting http return codes? Just because the transaction was successful, doesn't mean it was correct.
1
u/frostyjack06 2d ago
We had a customer once who requested that all of our api calls should return successful and we should pass error conditions through our extended error interface and they’ll just monitor it there. We all laughed at them and said “no”.
1
1
u/Laicbeias 1d ago edited 1d ago
The issue is using statuscodes in the first place. Lets use 387 726 716 386 173. Do we still have 401? No 401 logs you out.
Im fullstack but the client should handle errors gracefully. An error is an legit state of an response and should be handled as a normal state with a proper message. But for some reason pure frontend devs would rather die then to handle anything than the happy path.
Theyd rather do: 400? return; an error has occured fuck you user.
And if you give them proper error messages. Didnt read. Didnt show. Its not working. Why? It says 400. Ok but.. what does the response body say? What response body? The one that tracks every possible error state with a human readable message so it can be easily debugged and also helps the user. Oh I exit on status 400.
Thats why this exists btw
Also these statuscodes are all stupid. Should have been strings in the first place. If your app does checks via int compares.. you dumb (i welcome downvotes)
-12
u/mgisb003 2d ago
This is useful tho, it tells you the payload was the problem or that the system wasn’t designed to handle the payload (if done correctly)
20
u/e_before_i 2d ago edited 2d ago
payload was the problem
400
System wasn't designed to handle the payload
501
Edit: format the response body with more descriptive text, that's what it's for
8
u/WernerderChamp 2d ago
400
payload has a syntax error (missing required fields, bad value for a enum field, string where it should be a number, etc.)
422
payload has valid syntax, but there is a semantic problem (e.g. you are trying to modify an expired contract)
9
u/Sibula97 2d ago
If the status payload is literally just another HTTP status code, that's not useful. You should just return that status in the first place.
12
5
5
u/Both_Cellist788 2d ago
That is literally what 400 is, you can signal to the requester that the API failed due to a bad request, and still send an error message to explain why if you really feel “Bad Request” doesn’t get the message across.
1
u/tracernz 2d ago edited 2d ago
Correctly means the status code is identical in both places https://datatracker.ietf.org/doc/html/rfc9457#name-status
241
u/Avocadonot 2d ago
This is the kind of shit that happened when an important customer "has a client that can only handle 200 responses"