Re:API Practices If You Hate Your Customers
by e9 on Wednesday December 11, 2019 @06:05PM
(#21767746)
It 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.
[ Parent
| on HN ]
Re:API Practices If You Hate Your Customers
by davalapar on Wednesday December 11, 2019 @06:26PM
(#21767883)
If the server got an issue with your request it can return 400 (Bad Request), which means that the server has received it successfully before acknowledging it as a bad one.
Even then, if the server returns 400 (Bad Request) the server can still attach a response body to that, in plain text/plain, application/octet-stream or even application/json, which could contain elaborate information.
Re:API Practices If You Hate Your Customers
by wool_gather on Wednesday December 11, 2019 @06:26PM
(#21767887)
This is what the 400 and 500 ranges of HTTP status codes are for.
The former when the problem is on the client side, the latter for a problem on the server.
And you can still send a descriptive body for the error, if you so choose.
Re:API Practices If You Hate Your Customers
by jayd16 on Thursday December 12, 2019 @04:11AM
(#21770450)
This is not true. Counterpoint, responses like 404 or 503 Bad Gateway do not come from the destination server. They do not indicate the intended server received your request.
Re:API Practices If You Hate Your Customers
by sho on Thursday December 12, 2019 @05:16AM
(#21770746)
404 and 500 should come from the destination server. You are correct that 503 would not.
Re:API Practices If You Hate Your Customers
by jayd16 on Thursday December 12, 2019 @10:57AM
(#21772898)
Hmm are these assumptions valid? Can't a misconfigured load balancer cause a 404? Couldn't a bug in nginx, node or an app server produce a 500 response outside of your control?
I suppose a misconfigured load balancer or nginx instance could return absolutely anything. I think you'd have to be actually maliciously misprogramming it, though, to reach that level of dysfunction!
Re:API Practices If You Hate Your Customers
by paulddraper on Wednesday December 11, 2019 @06:22PM
(#21767859)
For 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".
Re:API Practices If You Hate Your Customers
by wool_gather on Wednesday December 11, 2019 @06:30PM
(#21767910)
No, the "completely invalid query" is 400.
404 is only for "the request makes sense but that specific resource doesn't exist".
Re:API Practices If You Hate Your Customers
by paulddraper on Wednesday December 11, 2019 @07:47PM
(#21768363)
400 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).
Re:API Practices If You Hate Your Customers
by akvadrako on Thursday December 12, 2019 @03:22AM
(#21770251)
In this case it’s a 404 because the query URL pattern doesn’t exist - the most common cause of 404s.
Re:API Practices If You Hate Your Customers
by pavel_lishin on Thursday December 12, 2019 @11:29AM
(#21773277)
Same thing, no? If I ask for /api/user/238885 and I get a 404 back, it's because the resource "user" with ID of 238885 doesn't exist. If I ask for /api/banana/wharrgarbl, it's because the resource "banana" with the ID of "wharrgarbl" doesn't exist.