Programmer Humor

{ "ok": false }

- My Chemical Romance

{ "ok": "false" }

 { "OK": "Ah ah ah, you didn't say the magic word." }

Or a link to a thread on microsoft answers that 404s

Honestly at this point if it's source available it's almost faster to dig through and find the affected module on source to determine behavior.

Unless of course it's just crazy abstracted, which can be an unintentional form of obfuscation when applied poorly.

This looks so over-engineered. Most of the time you only need an error message. Make the message clear enough so that it can be shown to the end user.

I have had that argument repeatedly with people. People insisting that HTTP error codes are "transport layer" and it's "wrong" for an API to hijack them to report "application level issues".

No, the whole point of "REST" was to map application semantics to HTTP in a way that actually normalizes some things like error handling and expectations around whether an operation could be expected to be idempotent and make the namespace navigable.

At one point my work announced a person who was an external hire to be the 'API genius' to set my company straight. He came from a super reputable well known company so of course he just the smart guy to fix our technical mess. He had sent a message saying that he had reviewed the teams API and concluded they were not restful. I had a glimmer of optimism, that someone recognized as authoritative would call the RPC style HTTP usage that always returned 200 and steer toward sanity, or at least honesty. No, his feedback was that was all fine, but REST does not use JSON, REST uses Protobuf, so they need to change to Protobuf to claim to be REST. Of all the what the hell I could have predicted, that one was not in my book...

Then just return a 500 - Server error. Nice and obscure.

The ability to separate "something wrong with what you sent" (4XX) and "something wrong on the server" (5XX) is very valuable in itself.

It's us: 5xx

It's you: 4xx

I don't wanna be pedantic but most things we call REST aren't REST. The original definition of REST is what we typically call HATEOAS. So when you say JAON API almost always means not REST you need to qualify that.

how would you return metadata or more detailed error codes?

And on the other side of this are JS devs that check for neither error response codes or error messages, and write an error into their own data as if it's the result they were after.

Always fun to see GET /orders/{error : "invalid branchID provided"} in your logs.

I'd easily take that over '200 for everything'. If at least errors are distinct from success, I'd take that as a win. My standards have been lowered by so many '200 for everything' backends..

That’s true, but for a good reason. GraphQL is transport agnostic, so using HTTP status to represent errors doesn’t make sense. HTTP is just a carrier for GraphQL, and the status code represents whether or not the HTTP part was successful.