DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
58% Positive
Analyzed from 1317 words in the discussion.
Trending Topics
#rest#api#more#web#comment#restful#spec#article#years#http
Discussion (33 Comments)Read Original on HackerNews
Problem Details (RFC 9457) are useful and have made an occasional appearance, but actual hypermedia driven APIs with custom media types seem to be non-existent outside of example blog posts. It's much more common to instead see APIs overload lesser-used HTTP status codes with their own domain-specific meanings. But if I'm being honest, this sort of protocol crime almost never caused an actual problem in practice.
The advocacy for "true REST" is missing a compelling argument and useful example of why it would actually be an improvement. Despite its prominence, for over 20 years almost nobody has used this approach. Why is that?
I do still have an aesthetic appreciation for "true REST", but in practice I find the fact that nobody uses it to be mainly useful in ending bikeshedding discussions. Once you understand your API isn't RESTful to begin with, there's no longer any point in arguing if 411 or 412 is the more RESTful status code to use when a user attempts to order a product without specifying a quantity. (Spoiler: neither is correct) You simply send a 400 with Problem Details and call it a day. Ironically, this indifference may make your API just a little bit more RESTful.
I think I have a fundamental objection to the idea that Fielding and Fielding alone got to decide what REST is. While there hasn't been any kind of formal counterproposal, in some sense REST is what we make of it. Re: http 400 codes, I think many of us really liked the general principle of "use http semantics!" and applied that to error codes as well. That's agreeing with the principle and extending it in new ways that we like and are "truer" to the principle, even if it wasn't intended.
In my mind this is sort of analogous to talking about the relationship between linux and unix. Linux is clearly not a genetic or copyright unix, but I've seen it said before that linux is the culmination of unix principles, in some cases extended beyond what was originally envisioned in ways that are innovative and genuine improvements (io_uring perhaps?).
The REST we have today - http semantics, specific error codes, etc - may be significantly different from what Fielding may have wanted, but IMO it implements the parts that really distinguish it from the RPC world of API architecture, and that's I think we're mostly generally happy with that.
There is one highly successful use of REST: the World Wide Web.
The Web/Web browsers are driven from hypermedia. (This is circular, as Fielding was looking at the web when making his dissertation.)
Granted, Web browsers stand alone as an application with extreme flexibility.
So REST is both highly common and very rare, depending on how you count.
To be honest, I just kind of don't understand the point. Could my API be better following some of these rules the author presented? Probably. But by how much? Is it worth it? When someone else on my team disagrees do we go back and argue about the spec again?
After 12+ years I'm just not sure anymore. If I'm using REST incorrectly (according to this article or others), but getting good results and everyone on the team is aligned, does it matter? I'm willing to have my mind changed this, maybe I'm missing something important
But that said, I'm okay with it not following the spec as long as things are clearly documented to end users. We just went through an issue where a prominent CDN provider exposing a REST API we depend on broke REST in a very important way (i.e. NOT stateless). It's extremely annoying to try and construct clients around nonstandard APIs, and the more REST-y, the less annoying.
Better to just pick something and go with it, then argue about the spec more
> REST (Representational State Transfer) is a software architectural style that was created to describe the design and guide the development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of a distributed, Internet-scale hypermedia system, such as the Web, should behave.
And isn't it always misused, mis-represented basically all the time? Often confused with things that are basically just JSON API(s)?
The article makes this point.
https://github.com/NationalBankBelgium/REST-API-Design-Guide...
Update: It clicked now…
https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
And here is why REST is probably largely pointless in machine-to-machine APIs:
https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
but people who didn't understand rest some of them migrated to graphql or rpc.
The example given in this section... is there actually a commonly used REST api that uses that particular key/structure? I wouldn't be _surprised_ if I came across that in some random API's documentation, but I hardly think it's the 'usual' thing to do.
The article later claims that that style is from https://stateless.co/hal_specification.html , which I think is a consultancy company whose major partners are all casinos (am I totally off on this?). The article also references (https://github.com/kevinswiber/siren which adds detail re: http methods embedded in the _links structure, but I'm not sure why that repo should be considered authoritative. 1300 stars for a just a spec is actually not bad though I think, so maybe.
Overall this article seems like slop produces from some kind of ai crawler that managed to dig up a couple of random links.
I am glad that it mentions rfc9457 though.
Conditional requests feel like the other omission. ETag and 304 are part of the same "use HTTP as intended" argument, and they change client behaviour more often than whether someone hardcoded a route.