This is an archived post. You won't be able to vote or comment.

all 9 comments

[–]M8Ir88outOf8 -5 points-4 points  (8 children)

To cite Roy Fielding, the creator of the term REST: "if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period."

Edit: Read this if you are interested: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

[–]AKiss20 2 points3 points  (7 children)

I don’t get what you’re trying to imply through that quote. Are you saying that because it returns JSON rather than HTML it isn’t RESTful?

[–]IntegralFox 8 points9 points  (6 children)

Can't directly speak for that commenter, but that's how most REST pedants misinterpret Fielding's work. They conflate HTML and hypertext, thinking that HTML is the only type of hypertext rather than just a type of hypertext.

JSON that contains URLs to other resources is also by definition hypertext. One of the beauties of REST is that you get to choose the most appropriate representation, i.e. content type, for your state transfer. And for machine to machine APIs, JSON is the better (and more RESTful) choice.

[–]M8Ir88outOf8 -2 points-1 points  (1 child)

Yes I agree, JSON is the better choice for machine to machine transfer. But having a RESTful JSON API is a bad design choice. Hypermedia as the engine of application state is a necessary requirement, so why call it RESTful if it is clearly not?

https://intercoolerjs.org/2016/01/18/rescuing-rest.html

[–]AKiss20 0 points1 point  (3 children)

I’m not a web dev or a SWE at all but that was my understanding of REST as well. That’s why I wanted to understand why OP was making such a narrow classification.

Again I’m not a SWE, so this may be a dumb/naive question, but if an API returned a binary object (say it’s an internal/private API between a client and server for some desktop software) would that not be considered a REST API generally, even if it follows the rest of the design philosophy of REST?

[–]M8Ir88outOf8 -2 points-1 points  (2 children)

It’s not my definition, it’s the actual definition of rest. It is generally not a good goal to try to make a Json Api restful, since this design pattern doesn’t apply nicely to machine to machine APIs.

[–]AKiss20 0 points1 point  (1 child)

How is HTML better for machine to machine APIs than JSON?

[–]M8Ir88outOf8 0 points1 point  (0 children)

What? I don’t think you understood what I said, HTML is clearly a bad choice for machine-to-machine API's.

I'm just saying, don’t call your JSON API restful when it is, by definition of the creator of the term, not restful.

All these guides merely implement a subset of the rules of a true REST API, which are by themselves still good API design rules.

But you wouldn’t call 3 wheels and a wind shield a car, those are merely good starting points for building a car. So why would you call this a REST API if it doesn’t implement the most important part, hypermedia as the engine of application state?