5 ms·

It makes absolutely no sense to even suggest that REST should be rebranded "HTTP API" or even "hypermedia API" because REST is neither protocol-specific nor is

by rualca 5y ago

It makes absolutely no sense to even suggest that REST should be rebranded "HTTP API" or even "hypermedia API" because REST is neither protocol-specific nor is "hypermedia" the only (or even main) design trait. It's like someone who is entirely unfamiliar with REST feels compelled to make bold statements about traits he doesn't fully grasp.

masklinn 5y ago
> nor is "hypermedia" the only (or even main) design trait. If you take REST as what it’s original author defined, then it absolutely is. Fielding literally has an article saying so: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... > REST APIs must be hypertext-driven If you take REST as what it’s become (a worthless buzzword for HTTP-based APIs) then > REST is neither protocol-specific Is wrong in turn. You can’t deny both. Unless you’ve decided to make it even more worthless and just a synonym for « API » I guess.
- rualca 5y ago
  > REST APIs must be hypertext-driven That's a reference to HATEOAS, but the whole point is that REST refers to an entire collection of design traits, where hypermedia is only one of them, and you cannot have REST if you do not meet other design requirements first, such as resource-driven architecture. Making REST all about HATEOAS is almost as bad as making REST all about hard coded paths to resources. > If you take REST as what it’s become (...) REST didn't became anything. It has always been the same thing. It's specification is set in stone in the doctoral thesis, and complemented with subsequent posts and public statements from the author. This sort of post has nothing to do with REST at all. It has zero to do with technology or design. This is vacuous and baseless buzzword bingo that adds nothing of value and just manifest a fundamental misunderstanding of the subject that is intended to be discussed. We already have RPC-over-HTTP. It's not REST, everyone knows that. That's a very old concept, as is the resistance to implement HATEOAS. There is nothing of value in this. It's just a clear sign that the author jumped to the part where he feels compelled to coin buzzwords by appropriating established and well-defined concepts while skipping the part he gets acquainted with the subject, thus showing a fundamental misunderstanding of the whole topic.
- jayd16 5y ago
  >A REST API should not be dependent on any single communication protocol I think hypertext is wider than HTTP as far as this blog post in concerned.
  - masklinn 5y ago
    > I think hypertext is wider than HTTP as far as this blog post in concerned. Yes? Did you wildly misread my comment? REST is either the original definition, in which it is hypertext-driven and protocol-agnostic, or a worthless buzzword for http APIs which are not hypertext-driven but are very much protocol-specific.
goto11 5y ago
It is the style of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. Because they are not really REST and don't need to be. He is not suggesting rebranding the architectural style known as REST.
- rualca 5y ago
  > It is kind of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. First of all, the title of the blog post is literally "should we rebrand REST?" Secondly, these appeals to rebranding REST APIs is already telling of the author's lack of familiarity and insight into the topic. The concept of RPC-over-HTTP is already widely established, as also the age-old stopgap solutions to REST misnomers and incoherences and buzzword abuses which is the Richardson maturity model https://martinfowler.com/articles/richardsonMaturityModel.html https://martinfowler.com/articles/richardsonMaturityModel.ht... I mean, look at the date that article was posted. 2010. It's over a decade old. This debate is not new, and is already solved. We know what REST is. We know that HATEOAS is a key part, and one that no one implements. We know that there are plenty of ignorant folks starving to put buzzwords on their CV. We know that most people end up using resource-driven RPC-over-HTTP with no hypermedia or discoverability. Just because a blogger failed to do his homework and happened to feel emboldened to coin new buzzwords that doesn't mean he's making any point at all or providing any value.
  - unscaled 5y ago
    The blog post explicitly mentions the Richardson Maturity model. He also says that even systems or designs are consciously trying to acheive Level 3 in the Richardson model (HATEOAS) such as JSON-LD with Hydra or JSON:API are still not RESTful in practice. This seems to be the main point of the article, but it is quite hidden. The idea of an app that can display and manipulate data on a distributed network of servers using a well-defined set of JSON-based content types is very interesting. But this is not what the vast majority of currently existing "REST APIs" (even those who are using a more hypermedia-oriented format like JSON:API or JSON-LD) are trying to do. I personally think it is too late to rebrand "REST". Like a lot of confusing names (NoSQL, Serverless, "Cloud", "JavaScript"), it is here to stay. But the main point the author is trying to make is that there are true Hypermedia API clients (which are virtually non-existent in the wild) and HTTP API with various concepts borrowed from the REST model (but are not fully RESTful themselves).

by rualca 5y ago

masklinn 5y ago

> nor is "hypermedia" the only (or even main) design trait. If you take REST as what it’s original author defined, then it absolutely is. Fielding literally has an article saying so: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... > REST APIs must be hypertext-driven If you take REST as what it’s become (a worthless buzzword for HTTP-based APIs) then > REST is neither protocol-specific Is wrong in turn. You can’t deny both. Unless you’ve decided to make it even more worthless and just a synonym for « API » I guess.

rualca 5y ago
> REST APIs must be hypertext-driven That's a reference to HATEOAS, but the whole point is that REST refers to an entire collection of design traits, where hypermedia is only one of them, and you cannot have REST if you do not meet other design requirements first, such as resource-driven architecture. Making REST all about HATEOAS is almost as bad as making REST all about hard coded paths to resources. > If you take REST as what it’s become (...) REST didn't became anything. It has always been the same thing. It's specification is set in stone in the doctoral thesis, and complemented with subsequent posts and public statements from the author. This sort of post has nothing to do with REST at all. It has zero to do with technology or design. This is vacuous and baseless buzzword bingo that adds nothing of value and just manifest a fundamental misunderstanding of the subject that is intended to be discussed. We already have RPC-over-HTTP. It's not REST, everyone knows that. That's a very old concept, as is the resistance to implement HATEOAS. There is nothing of value in this. It's just a clear sign that the author jumped to the part where he feels compelled to coin buzzwords by appropriating established and well-defined concepts while skipping the part he gets acquainted with the subject, thus showing a fundamental misunderstanding of the whole topic.
jayd16 5y ago
>A REST API should not be dependent on any single communication protocol I think hypertext is wider than HTTP as far as this blog post in concerned.
- masklinn 5y ago
  > I think hypertext is wider than HTTP as far as this blog post in concerned. Yes? Did you wildly misread my comment? REST is either the original definition, in which it is hypertext-driven and protocol-agnostic, or a worthless buzzword for http APIs which are not hypertext-driven but are very much protocol-specific.

goto11 5y ago

It is the style of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. Because they are not really REST and don't need to be. He is not suggesting rebranding the architectural style known as REST.

rualca 5y ago
> It is kind of API's people commonly call REST API's which he suggest should be rebranded to HTTP API's. First of all, the title of the blog post is literally "should we rebrand REST?" Secondly, these appeals to rebranding REST APIs is already telling of the author's lack of familiarity and insight into the topic. The concept of RPC-over-HTTP is already widely established, as also the age-old stopgap solutions to REST misnomers and incoherences and buzzword abuses which is the Richardson maturity model https://martinfowler.com/articles/richardsonMaturityModel.html https://martinfowler.com/articles/richardsonMaturityModel.ht... I mean, look at the date that article was posted. 2010. It's over a decade old. This debate is not new, and is already solved. We know what REST is. We know that HATEOAS is a key part, and one that no one implements. We know that there are plenty of ignorant folks starving to put buzzwords on their CV. We know that most people end up using resource-driven RPC-over-HTTP with no hypermedia or discoverability. Just because a blogger failed to do his homework and happened to feel emboldened to coin new buzzwords that doesn't mean he's making any point at all or providing any value.
- unscaled 5y ago
  The blog post explicitly mentions the Richardson Maturity model. He also says that even systems or designs are consciously trying to acheive Level 3 in the Richardson model (HATEOAS) such as JSON-LD with Hydra or JSON:API are still not RESTful in practice. This seems to be the main point of the article, but it is quite hidden. The idea of an app that can display and manipulate data on a distributed network of servers using a well-defined set of JSON-based content types is very interesting. But this is not what the vast majority of currently existing "REST APIs" (even those who are using a more hypermedia-oriented format like JSON:API or JSON-LD) are trying to do. I personally think it is too late to rebrand "REST". Like a lot of confusing names (NoSQL, Serverless, "Cloud", "JavaScript"), it is here to stay. But the main point the author is trying to make is that there are true Hypermedia API clients (which are virtually non-existent in the wild) and HTTP API with various concepts borrowed from the REST model (but are not fully RESTful themselves).