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-b

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.