Yes, there are certain things that don't map to key principles of REST, and I have upon occasion see people way too hooked on purity of REST for any practical end.

However, to the extent that you at least consider how it could map, then that's helpful.

If you say "you can't have an application error, you must ONLY use HTTP error codes", that would be bogus. But if your application knows it has an error, why not also set HTTP status code to indicate an error as well? You have to set a status code anyway, might as well at least get the first digit right, or just 500 == error, 200 ==OK if you don't want to hash out 4XX v. 5XX.

REST may not be sufficient, but that doesn't mean it's helpful to actively work against the HTTP semantics when they could be a vague indicator consistent with your API.

[–] ryathal@sh.itjust.works 1 points 2 days ago (1 children)

There's also value in treating http as just a transport later. It can give you clear boundaries, 200 the app processed the request, anything else the app didn't process it.

[–] jj4211@lemmy.world 2 points 2 days ago

But what is the value of a 200 OK when the request absolutely failed? As a caller, I don't care that it successfully was conveyed but still utterly failed. Depending on my usage, I may only care about pass/ fail and the backend insisting I have to handle multiple different ways of expressing failure is just more work with no value.

Using 500 does nothing to preclude your application errors. If the caller wants nuance, it can still have it in the body or headers.