3 ms·

> 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

by 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

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).