Like other posters have said, the author appears to be pointing out shortcomings with HTTP, not REST. Roy Fielding made it fairly clear that REST is not strictly associated with HTTP. REST, as an architectural style, is defined by a set of constraints: https://en.wikipedia.org/wiki/Representational_state_transfe.... Anything that meets these constraints is considered "REST". Most of the constraints sound like common sense for API design, and where most APIs are disqualified from being truly "REST" and merely "RESTish" is in trying (or not) to fulfill the Uniform Interface/HATEOAS constraint: that the client dynamically traverses information and operations from one resource to another via hypermedia links.
Interestingly there's yet a deeper problem with fully RESTful APIs (Hypermedia APIs), where REST's Stateless Protocol constraint combined with HATEOAS creates an API where clients need to undergo multiple HTTP round trips to load the data they need. For example, suppose your app lets users browse movies. You might have a sequence like:
client: "hey, I'm gonna act like a browser and hit api.com and take it from there"
GET api.com
=>
{
"movies": {
"rel": "content/movies",
"href": "/movies"
}
}
client: "hmm, ok I guess I'll click the movies link"
GET api.com/movies
=>
{
"items": {
"count": 4,
"prev": null,
"next": "/movies/page/2",
[
{"href": "/movies/1"},
{"href": "/movies/2"},
{"href": "/movies/3"},
{"href": "/movies/4"},
]
}
}
client: "ok, I guess I'll fetch each of those movies (I kinda wish the server had just told me what those contents were in the first place)"
GET api.com/movies/1... etc.
=>
{
"href": "/movies/1",
"rel": "self",
"title": "Waterworld",
"image": "/images/waterworld.png",
}
...
And don't forget the client-side logic to join/order all this data and handle errors. This problem is called "underfetching" and it's present in true REST APIs by design. Ironically, many "RESTful" APIs break from the REST constraints specifically to avoid this problem.
> Roy Fielding made it fairly clear that REST is not strictly associated with HTTP. REST, as an architectural style, is defined by a set of constraints:
Out of curiosity, do you know of any examples of RESTful APIs that use a protocol other than HTTP (say like IMAP or NNTP)?
He isn't going to provide you an example because there is none meaning full in production. REST uses HTTP because it makes no sense to use it with anything else. REST only makes sense with HTTP. With another socket protocol, there is no need to bother with headers and co.
You're right, there are no other protocols at nearly the scale of HTTP that use REST. I was just pointing out that REST was not strictly associated with HTTP in Roy Fielding's definition. If you look at my other link (Richardson Maturity Model), you can see that RPC-over-HTTP is vulnerable to same criticisms in the OP's link. Hence, I think the issues discussed in the article don't singularly apply to REST.
That is the the real test beyond technical jargon and If someone provides a working example that works over different protocols as you have suggested that will be end of discussion :)
Interestingly there's yet a deeper problem with fully RESTful APIs (Hypermedia APIs), where REST's Stateless Protocol constraint combined with HATEOAS creates an API where clients need to undergo multiple HTTP round trips to load the data they need. For example, suppose your app lets users browse movies. You might have a sequence like:
client: "hey, I'm gonna act like a browser and hit api.com and take it from there" GET api.com => { "movies": { "rel": "content/movies", "href": "/movies" } }
client: "hmm, ok I guess I'll click the movies link" GET api.com/movies => { "items": { "count": 4, "prev": null, "next": "/movies/page/2", [ {"href": "/movies/1"}, {"href": "/movies/2"}, {"href": "/movies/3"}, {"href": "/movies/4"}, ] } }
client: "ok, I guess I'll fetch each of those movies (I kinda wish the server had just told me what those contents were in the first place)" GET api.com/movies/1... etc. => { "href": "/movies/1", "rel": "self", "title": "Waterworld", "image": "/images/waterworld.png", } ...
And don't forget the client-side logic to join/order all this data and handle errors. This problem is called "underfetching" and it's present in true REST APIs by design. Ironically, many "RESTful" APIs break from the REST constraints specifically to avoid this problem.
Another great article on REST APIs: https://martinfowler.com/articles/richardsonMaturityModel.ht...