Yep, I’ve got one of these at work now. Technically, 200 can make sense here if you’re using HTTP as RPC transport, as the server relayed the request to its handler and returned the outcome, but damn if it’s not annoying to actually process the response.
I’ve also seen a lot of devs tie themselves into knots trying to map various execution types to the “semantically correct” HTTP code, but the thing is the abstraction of HTTP is not based around RPC and it’s ultimately a pretty weird fit that we’ve somehow come to view as normal.
Aaagh! Getting some random old person flashbacks.
Kids. I r-remember a day… You won’t believe this… I got a 404 error page… It was otherwise a normal 404 page with a normal message on it, but it had a giant ad on it… like “while you’re here, how about you buy this stuff”… It was hell… You’ve got no idea how lucky you kids are with uBlock…
{ "ok": false }{ "ok": false }{ "ok": "false" }{ "false": "ok" }$false=true
{ "ok": "no" }
error = true with no description or answer is basically ten years of searching stackoverflow and reddit threads for an answer.
It’s not us, it’s you
It’s us: 5xx
It’s you: 4xx
Marketo my
belovedthe bane of my existence. Actually without a doubt the worst API I’ve ever worked with in my career. The response schemas are random and a 200 means nothing because it might also include a “success”: “false”". Our backend API is Python and we have strict typing rule but Marketo really makes that difficultCongratulations! You failed.
JSON API almost always means “not REST”. In other words, it works as intended.
how would you return metadata or more detailed error codes?
However you like, REST doesn’t dictate anything there. Just be consistent and use hypermedia.
JSON APIs almost never follow REST because they almost never use JSON as hypertext. Worse, no complete stable hypertext JSON standard exists. There’s JSON-HAL, but it lacks a way to represent resource templates (think HTML’s
<form>).Therefore, with JSON APIs ignoring one of the most basic idea behind REST, why would anyone expect them to follow another idea of REST - consistency?
REST is a deceptively simple concept. Any time you build an HTML website a human can navigate without consulting documentation, you’re doing it better than vast majority of swagger documented corporate APIs.
The argument probably goes something like " if you adhere strictly to REST the error codes are all you need" and then metadata can be sent in response headers.
how should a REST API respond to the client sending a URL the ends in a string instead of a numeric ID? like api.social/users/ceeforayteen instead of api.socail/users/11037
I would do a 400 (Bad Request). Then, with varying amounts of detail depending on the scale of the project and the framework capability, the response body would be something like: { “error”:true, “reason”: “validation”, “detail”: “user id should be numeric” }
Depends on the verb and the application. If the string is valid 200, if it isn’t 400, 404.
It’s still just another type of ID so you can do lookups on it. Nothing would change. UUIDs are used all the time.
Every time I see someone recommend this at work I die a little inside. Like… C’mon!
Either way, the webpage didn’t load. And fuck literally everyone involved for not explaining to me what I need to do to fix it.
I’d rather see this than actual rest or the more popular use the bits of rest that are convenient.
