5 ms·

> And these ‘simple’ URLs can be a pain when you want to extend them with more parameters, or even use more complex types like an array as a parameter. Except

> And these ‘simple’ URLs can be a pain when you want to extend them with more parameters, or even use more complex types like an array as a parameter. Except in REST, a resource would not be identified by an array. If the resources would be a list and you would want to filter it, you would indeed use query parameters. I do not see that the article brings up valid concerns at all. It seems to me, that the author just wants to simplify something, which is already quite nice and simple. REST is a common standard, that fits nicely on top of HTTP. Why not use standard error codes if they are already available and commonly known? Isn't that the whole point about standards, that people know them and are therefore already better informed without knowing your specific implementation? I understand criticism against religiously following standards when they are hard to implement or the benefit is marginal. I for example get, using cookies for authentication of an internal API. I don't see the point of restricting myself to POST and 200/500 error codes, the extra work here to conform to REST is minimal while the benefit to the consumer is clear.

MichaelGG 12y ago
Because the HTTP error codes simply don't cover the errors of actual applications? So you end up returning the real error code in the body anyways. Now client apps need to check two different places for errors. (For instance, what's the error for "request can be completed but not with the price restriction you've set on your account" vs " request can be completed, but not for the price we've committed to", and "request cannot be completed because we don't have any available prices". That's three real errors we had to return over SIP, which takes the HTTP error model. You know what everyone does applying to billions of calls per day? Send back 503 on basically everything, except busy which happens to have it's own useful code.
- allendoerfer 12y ago
  What about 402 or 409? But that was not really what I meant. In your case, it does not cost the API-owner anything to use 503 instead of 500, he has to provide an additional message anyway. If instead a more common error occurs, it is just nice for the client to get a standard status code, that is known by frameworks and libraries and can potentially already be handled at that level. Just because something can not be standardized entirely does not mean you should not standardize parts of it.

MichaelGG 12y ago

Because the HTTP error codes simply don't cover the errors of actual applications? So you end up returning the real error code in the body anyways. Now client apps need to check two different places for errors. (For instance, what's the error for "request can be completed but not with the price restriction you've set on your account" vs " request can be completed, but not for the price we've committed to", and "request cannot be completed because we don't have any available prices". That's three real errors we had to return over SIP, which takes the HTTP error model. You know what everyone does applying to billions of calls per day? Send back 503 on basically everything, except busy which happens to have it's own useful code.

allendoerfer 12y ago
What about 402 or 409? But that was not really what I meant. In your case, it does not cost the API-owner anything to use 503 instead of 500, he has to provide an additional message anyway. If instead a more common error occurs, it is just nice for the client to get a standard status code, that is known by frameworks and libraries and can potentially already be handled at that level. Just because something can not be standardized entirely does not mean you should not standardize parts of it.