3 ms·

> Yes, that's essentially their point—REST started as a description of a good hypertext architecture and was coopted to describe just about any JSON API. HATEOA

by rewmie 3y ago

> Yes, that's essentially their point—REST started as a description of a good hypertext architecture and was coopted to describe just about any JSON API. HATEOAS only makes sense in the original context. I don't think that your opinion is valid. What you refer as "JSON API" is actually just resources being represented with a specific JSON-based media type, in the same way that opening a page is actually a resource represented as a HTML-based media type. Some web scrapers are basically HATEOAS clients.

myk9001 3y ago
I believe the grandparent is making a valid point. It depends on implicit assumptions we have in mind reading it. The way I'm reading your comment, that JSON-based (or XML-based, or some binary format-based for that matter) media type encodes hyperlinks in some form. Then the client is a simplified, specialized browser, if you will. But the mechanics of client/server interaction are essentially the same as a "traditional" web application (as in Django, RoR, PHP, etc). And if it's a machine-to-machine interaction, the client is very simalar to a web crawler/scraper, although the media types it parses is not necessary HTML. In other words, you are absolutely right in that REST is non confined to HTML. What the grandparent means by JSON API, I think, is the kind of HTTP API we are used to see designed for mobile and SPA clients -- pretty URIs for endpoints, HTTP methods, JSON-serialized request/response bodies... Those can actually be very nice API, pleasant to work with. It's just that it's not REST. But at this point, it's probably more productive to go with the flow and just accept people refer to such API as REST. That said, to me, understanding the difference is still valuable. Even if I'm not going to mention it out loud in a work setting.

3 ms·

> Yes, that's essentially their point—REST started as a description of a good hypertext architecture and was coopted to describe just about any JSON API. HATEOA

by rewmie 3y ago

myk9001 3y ago
I believe the grandparent is making a valid point. It depends on implicit assumptions we have in mind reading it. The way I'm reading your comment, that JSON-based (or XML-based, or some binary format-based for that matter) media type encodes hyperlinks in some form. Then the client is a simplified, specialized browser, if you will. But the mechanics of client/server interaction are essentially the same as a "traditional" web application (as in Django, RoR, PHP, etc). And if it's a machine-to-machine interaction, the client is very simalar to a web crawler/scraper, although the media types it parses is not necessary HTML. In other words, you are absolutely right in that REST is non confined to HTML. What the grandparent means by JSON API, I think, is the kind of HTTP API we are used to see designed for mobile and SPA clients -- pretty URIs for endpoints, HTTP methods, JSON-serialized request/response bodies... Those can actually be very nice API, pleasant to work with. It's just that it's not REST. But at this point, it's probably more productive to go with the flow and just accept people refer to such API as REST. That said, to me, understanding the difference is still valuable. Even if I'm not going to mention it out loud in a work setting.