That people misused REST is not what made REST "never that good" (in your opinion). In fact, it was this misuse that frustrated Dr. Fielding more than anything else.
> That people misused REST is not what made REST "never that good" (in your opinion).
I used to be partial to that interpretation, but after a few years of looking at it, at what people do and at what's actually valuable, I've come to the conclusion that coldtea is correct: REST as originally intended was not that good for programmatic contexts.
It certainly didn't help that it got quickly buzzwordified as "actually use HTTP properly instead of just shoving your garbage through POST all the time" (the original sin of SOAP or XML-RPC), but even then what makes "REST" work for browsers (which is what the concept was extracted from) is that there is an intelligent agent doing the discovery and driving the interaction.
That's not useful for a programmatic API. You can add a discovery layer to a programmatic API (as e.g. graphql schemas & explorer tools) but requiring programmatic clients to go through such a discovery layer just makes interacting with the API painful for no value.
Traversing a few pages when clicking around in your browser makes sense, doing so from a programmatic client when you could literally just store the correct endpoint and perform your call directly is nonsense: it's inefficient, it's annoying and it's pointlessly verbose. Yet that is essentially what proper rest as described and clarified[0] by Fielding require.
Even the "multiple interpretations" (multiple content types) option is worthless when browsers don't provide the flexibility required to do content negotiation[1] or leverage HTTP verbs beyond GET and POST.
[1] even in places where they allow actual mimetypes it's as likely as not they'll ignore it e.g. object/@type is a mimetype but no browser I know cares about it, most of them send Accept: ∗/∗ and firefox sends its pagewise/default Accept.
> That's not useful for a programmatic API. You can add a discovery layer to a programmatic API
A discovery layer isn't necessary if you're using hypermedia as intended. "Discovery" just means a loosely coupled format associates the "logical" addresses, which your program shouldn't know a priori, with a readable name, which your program uses to find the logical addresses it actually needs.
It's like the difference between programming in assembly language with direct memory addresses (URLs), vs using a programming language that abstracts memory addresses with named variables (hypermedia format that associates readable names to URLs), thus decoupling clients from needing to understand potentially opaque URL formats.
The real problem with REST is that REST frameworks don't provide any guidance or support for any hypermedia format that isn't HTML, and HTML isn't well suited to programmatic interaction. None of the commonly used data interchange formats support distinguishing embedded links from other data, so they aren't hypermedia formats. No wonder doing REST right is so difficult.
> doing so from a programmatic client when you could literally just store the correct endpoint and perform your call directly is nonsense: it's inefficient, it's annoying and it's pointlessly verbose.
Except it's not pointless, it allows painless server-side upgrades. It might cost you some efficiency, but it provides significant flexibility.
> Traversing a few pages when clicking around in your browser makes sense, doing so from a programmatic client when you could literally just store the correct endpoint and perform your call directly is nonsense:
That requires implicit knowledge of the 'correct' endpoint.
If that endpoint changes or anything in between, you'll have to start versioning your API, which basically tells all existing clients: Sorry, you got to update.
Allowing clients to discover resources is a future-proof way to keep your client libraries compatible and evolve your API without versioning.
It is more work for the client and it is not always suitable.
But if you intend to design something future-proof (and we are talking about 10+ years), then REST has already proven to be very successful (your latest browser can still browse a web page from 15 years ago...)
> That requires implicit knowledge of the 'correct' endpoint. If that endpoint changes or anything in between, you'll have to start versioning your API, which basically tells all existing clients: Sorry, you got to update.
In exactly the same way that the "RESTful" version requires implicit knowledge of the content types: that knowledge it not implicit at all, it is specifically and explicitly embedded in the system.
The word you're looking for is static.
> Allowing clients to discover resources is a future-proof way to keep your client libraries compatible and evolve your API without versioning.
That is completely untrue.
> But if you intend to design something future-proof (and we are talking about 10+ years), then REST has already proven to be very successful (your latest browser can still browse a web page from 15 years ago…)
Because it has a somewhat intelligent and flexible human driving it and able to adapt in changes to the visited targets. Not so with a programmatic client.
Exactly. And also: a UI could be badly designed even if its users don't misuse it.
Just because users might be extra careful in their use of a UI, doesn't mean the UI is not badly designed itself.
A big red button that says "Click me for free lemonade" but instead burns the whole computer is bad design -- even if the users have read the manual, so they know what it does and don't press it.
I used to be partial to that interpretation, but after a few years of looking at it, at what people do and at what's actually valuable, I've come to the conclusion that coldtea is correct: REST as originally intended was not that good for programmatic contexts.
It certainly didn't help that it got quickly buzzwordified as "actually use HTTP properly instead of just shoving your garbage through POST all the time" (the original sin of SOAP or XML-RPC), but even then what makes "REST" work for browsers (which is what the concept was extracted from) is that there is an intelligent agent doing the discovery and driving the interaction.
That's not useful for a programmatic API. You can add a discovery layer to a programmatic API (as e.g. graphql schemas & explorer tools) but requiring programmatic clients to go through such a discovery layer just makes interacting with the API painful for no value.
Traversing a few pages when clicking around in your browser makes sense, doing so from a programmatic client when you could literally just store the correct endpoint and perform your call directly is nonsense: it's inefficient, it's annoying and it's pointlessly verbose. Yet that is essentially what proper rest as described and clarified[0] by Fielding require.
Even the "multiple interpretations" (multiple content types) option is worthless when browsers don't provide the flexibility required to do content negotiation[1] or leverage HTTP verbs beyond GET and POST.
[0] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
[1] even in places where they allow actual mimetypes it's as likely as not they'll ignore it e.g. object/@type is a mimetype but no browser I know cares about it, most of them send Accept: ∗/∗ and firefox sends its pagewise/default Accept.