8 ms·
I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API wher
by Fradow 7y ago
I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough".
I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors.
When pointed out, the support answer was "we chose to give meaningful error messages instead of HTTP codes, that's why we respond with 200 in case there's an error in the request". Not the answer I was expecting.
Another annoying practice is to answer 2XX, put the request in a queue, and not provide ANY information about the queue, which can be minutes or even HOURS long. Debugging is a nightmare. The one I worked with who did that did not even have the excuse of being a startup or small company.
- save_ferris 7y ago> decided everything should return 200 Sounds like that decision came from someone who didn’t spend much of their career consuming APIs.
- avgDev 7y agoBut they are higher ups and should obviously be allowed to make ALL decisions, why listen to some developer who is beneath them. That dev has only spent the last 5 years working with APIs, databases, and web applications, what does he even know, probably nothing? /s
- jeltz 7y agoI spent a quite big part of my career consuming APIs and an API which always return 200 is no big deal. The opposite which I have also encountered is much worse, returning successes with 4XX, because some libraries do not like that. Why does the opposite happen? Because sometimes it is not obvious if something is an error or just another return value.
- avgDev 7y agoHa, I love it when people make dumb excuses for awful decisions like that. /s I much prefer colleagues who can say, woah that was dumb thanks for informing me of a better way. Making excuses doesn't help anyone unless one has a valid logical reason they did a certain thing, otherwise I DONT WANNA HEAR IT.
- toomuchtodo 7y agoThe people who write the API and the people who are tasked to provide support for it are usually not the same. If these are APIs between internal business units, my condolences, no excuse.
- iamthepieman 7y agoThis isn't the ArcGIS Server API is it?
- nobleach 7y agoMan that thing is a mess, isn't it....
- Fradow 7y agoNo this isn't. Without calling out names, the first one is a small localization platform (but seems to be a very prevalent issue in multiple APIs) and the second is an international hosting provider. Both are good enough for my case to overlook those issues, that are nevertheless infuriating.
- e9 7y agoIt depends. I've seen bigco use this technique and their reason was that they wanted to separate problems with API and request from actual issue with their servers/platform. So if you get 200 it means they received request successfully but if there is issue with request they'll include error in response with 200. If it's anything else then there is a networking or delivery problem. It's not standard way to handle things but can be useful at times.
- anoncake 7y agoHow is this better than using different status codes depending on the type of problem?
- paulddraper 7y agoFor example, suppose you want to distinguish between a missing/deleted resource /myuser/23123 and a completely invalid query /muser/23123. Both of these are 404 (or 410 for permanent caching) responses according to HTTP, though they have very different reasons for "non-existance".
- wool_gather 7y agoNo, the "completely invalid query" is 400. 404 is only for "the request makes sense but that specific resource doesn't exist".
- paulddraper 7y ago400 is a very generic error. It is often used to complain about problems with the request body. Considering how brief the HTTP RFC is, your interpretation is I think as good as any, if very uncommon. (Not what Django, Rails, Flask, etc. do).
- akvadrako 7y agoIn this case it’s a 404 because the query URL pattern doesn’t exist - the most common cause of 404s.
- deleted 7y ago[deleted]
- reificator 7y agoIIRC cross domain requests are often one of the causes for this style of API design. I remember in older browsers at least anything not in 2XX would be unreadable by the client, so they had no idea what actually went wrong on the frontend.
- zonidjan 7y agoThat's... extremely rare, extremely ancient, and even then was usually only a problem below a certain page length.
- rsynnott 7y ago> I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. I've done something like this in the past. There was a (horrible) reason; old versions of Android had terrible built-in HTTP stuff and tended to break on any 'unusual' HTTP responses (for instance, 204), especially where HTTP compression was enabled. By far the safest way to support clunky old Androids turned out be be just return 200 for everything with the real code embedded elsewhere...
- NicoJuicy 7y agoUgh, i'd put a gateway in front of it that transformed the status codes to a 200-response. Instead of building your api according to the default Android client ( ps. Lookup BFF microservices)
- rsynnott 7y agoIt was a while ago, and we were very cost sensitive. FWIW, I think the last Android phones with these client issues have probably died by now (it got mostly sorted out in 4.3 or so IIRC); this isn't a current concern.
- NicoJuicy 7y agoJust pointing out an alternative that wouldn't break/uglify your api ;)
- eecc 7y agoSounds familiar... ugh
- celticmusic 7y ago> When pointed out, the support answer was "we chose to give meaningful error messages instead of HTTP codes, that's why we respond with 200 in case there's an error in the request". Not the answer I was expecting. I don't see the problem here. As a developer I'd much rather receive a standard json packet with information helping me figure out what went wrong. I really don't understand your complaint here, I've designed and worked with both types of API's, and I find the standard json format to be far easier to deal with.
- wwweston 7y agoTotally agree that specific messaging is very convenient, but meaningful error messages and meaningful status codes aren't even remotely mutually exclusive. It's perfectly legitimate and even easy to send a 4xx or 5xx with a response body as JSON (or, for bonus points, with any other content type the client requests from possible server capabilities). And in my experience, having an out-of-body/band general indicator that doesn't require you to parse message responses makes things WAY easier. Well-designed APIs do both.
- celticmusic 7y agoI'm curious, what tech stack are you working in where parsing json is difficult? You want to talk about inconsistent? How about a 500 error may or may not result in the standard response format you're expecting because it may be coming from the server and it may be coming from the API. I'd much rather my 500 errors be legitimate server problems.
- zonidjan 7y agoWhether there's a bug in the underlying API code, or a bug in the web server, there's a risk that it "may or may not result in the standard response format you're expecting", and therefore... should be a 500 error. Yes, using the wrong status codes is a problem, you're right, that's the entire point of the thread you're responding to.
- 7y ago
- skunkworker 7y agoI had that when I was dealing with the Withings API. Oh you got a 4XX error? Here is a 200 back with a json payload of {error: 400, message: "Some message"}. Ugh it was frustrating.
- WrtCdEvrydy 7y agoSo I wasn't wrong. I fought someone over this and someone else was like 'looks okay to me'...
- Swizec 7y agoI’ve heard the argument as: “HTTP errors for protocol level errors, 200 + json for application level errors” And honestly it kinda make sense when you think about it that way. “404, wrong url” and “404, id not found” should be different errors.
- deergomoo 7y ago> “404, wrong url” and “404, id not found” should be different errors I'd actually argue the opposite, though I can definitely see both sides. To me, because two systems communicating RESTfully need not know anything about each other, responding to "please give me the resource as this URI" with "there is no resource at that URI" seems perfectly correct. I don't really need to know the specifics of how the remote machine is dealing with my request. If more detail is required you can always include a message in the request body, which I think should be standard practice for handled errors anyway.
- toast0 7y ago> I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. If all of your errors line up perfectly with HTTP, I guess this could work. But if you've got something that doesn't fit, or two things that would map to the same one, it gets weird. And then you have http client libraries that do great things like only return response bodies if status 200, or only return http statuses they were aware of. It's not very RESTful to just return http 200 with an embedded application status, but it's easy and consistent, and I would not write an HTTP api otherwise, unless I was had a good reason to follow some existing spec that used statuses.
- donmatito 7y agoSlack API does that too (to their credit, the docs are very complete and clear, even if their API design is questionable)
- dualscyther 7y agoI've found that returning 200 with errors seems to be the sane way to do things, since sometimes it's difficult to tell whether a server error belongs in the http later or graphql layer.
- lloydatkinson 7y agoI experienced something similar with a currency value API. Every response was 200 OK with a field containing the actual HTTP error if there was one. I made an issue on their GitHub explaining why that made consumers code messier than it should be and asked if they could fix it. They replied saying sure, but after several months they closed the issue without a fix and then refused to reply further, and then went and did a 360 degree rebrand of the company changing the pricing model and the API itself. I ripped out usage of their garbage API and replaced it with another almost immediately.
- jayd16 7y ago>I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. So here's the deal with this pattern...If you're returning a typed error response, something the client application should interpret, you want to be able to know which error responses will actually have that body and will not be a generic error like a 404 or a 503. If the response code is 200, you can be generally sure that the response came from the target host. Thus, the client knows they can parse an api level error from a 200 response and they should not attempt to parse non-2XX responses. I don't love the pattern but its not completely pointless. Does anyone know if the HTTP spec guarantees codes in 4XX range should only come from the intended host? It seems like 400 is a safe bet but I've never double checked myself.
- mleonhard 7y agoThe client should try to parse the response body only if it has the appropriate Content-Type header value. It should not assume that responses with various status codes have a particular body format.
- jayd16 7y agoDo you suggest having a content-type header specific to your app? Something like "application/my-app+json"? Will most tooling handle this correctly? In my experience the always 200 api style is a lot more common.
- jeltz 7y agoI have integrated against many weird B2B APIs and those who always return 200 are actually pretty nice to work with so even if it is a weird choice as an API consumer I do not mind it all, there are much worse things you can do.
- diehunde 7y agoI think that 200 status code for everything is such a bad practice. I'm surprise the amount of people here that are OK with that.