The point about the World Wide Web being an implementation of REST was really interesting, and now that I think about it web pages are one of the few things that usually respect HATEOAS. I'm reminded of one article by the author of intercooler.js and htmx, "HATEOAS is for Humans" (https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...), that made the same point but that I didn't understand fully when I read it.
Should we rebrand REST?
41–50 of 154 posts
Re: Should we rebrand REST?
#42Earlier quoted context omitted.
The problem is not REST per se, the problem is people thinking a machine-to-machine API "should" conform to REST. I have not seen a coherent argument for why HATEOAS should be a useful property for API's beside "REST says so". That said, we should not throw the baby out with the bathwater. Some REST principles like statelessness are good design for API's also.
100% agree, HATEOAS is rather useless for machine-to-machine. And it shouldn't come as a surprise that most APIs decide to not commit to this design constraint. I prefer to think of real-world APIs as coming in varying degees of RESTfulness depending on the design constraints they have chosen to conform to. Good engineering is about making judicious analysis of the trade-offs involved, if HATEOAS doesn't bring you an…
HATEOAS is somewhat useful even in machine-to-machine: hard-coded URLs in clients are kind of a PITA to support.
Re: Should we rebrand REST?
#43Earlier quoted context omitted.
100% agree, HATEOAS is rather useless for machine-to-machine. And it shouldn't come as a surprise that most APIs decide to not commit to this design constraint. I prefer to think of real-world APIs as coming in varying degees of RESTfulness depending on the design constraints they have chosen to conform to. Good engineering is about making judicious analysis of the trade-offs involved, if HATEOAS doesn't bring you an…
HATEOAS is somewhat useful even in machine-to-machine: hard-coded URLs in clients are kind of a PITA to support.
What is the problem with hard-coded URLs? It is certainly simpler than having to extract the URLs from some other request. If they don't change (and they shouldn't!) I don't see the problem.
Re: Should we rebrand REST?
#44I've given up on REST and I build all my new APIs with JSON-RPC. https://www.jsonrpc.org/specification Super simple. I'm not a fan of the complexity things like gRPC introduce to most languages (the PHP tooling is horrible for example), and I really don't like the limitations of HTTP verbs and the box that trying to confirm to CRUD puts you in.
I second this (although I'd just stick with JSON-RPC 1.0). REST has its uses case, but alas it's now so ubiquitous that developers don't even think about wether they should or should not use it.
For machine to machine communication between heterogenous systems, the simplicity of JSON-RPC means one can implement a client easily in any language. Also creating method stubs is trivial. The payload is still human-readable should you use it from the browser and it's not prone to debates and interpretations around the meaning of HTTP verbs. All you have to know is what method you want to call and with what arguments... something that is natural to all developers, while they almost always get the endpoints/resources/verbs thing wrong.
Re: Should we rebrand REST?
#45Earlier quoted context omitted.
100% agree, HATEOAS is rather useless for machine-to-machine. And it shouldn't come as a surprise that most APIs decide to not commit to this design constraint. I prefer to think of real-world APIs as coming in varying degees of RESTfulness depending on the design constraints they have chosen to conform to. Good engineering is about making judicious analysis of the trade-offs involved, if HATEOAS doesn't bring you an…
HATEOAS is somewhat useful even in machine-to-machine: hard-coded URLs in clients are kind of a PITA to support.
To be fair, you need at least one hard-coded URL in your client, don't you? To hit the root entrypoint.
And if you have one hard-coded URL... and use it as the root of other URLs, then it's no hard to support than anything.
URLs are useful in REST because the API often crosses domain boundaries and company boundaries. One site links to another and so on. Most APIs are not like that.
In fact they're only like that when they serve, say, static image assets off a CDN, and guess what, then passing back a URL in your API is self-evident and natural.
But not for everything IMHO.
Re: Should we rebrand REST?
#46Well-written article. Its always fun to inspire coworkers/peers to actually read Fielding's dissertation and then have a proper discussion about what REST actually is/means. There are those who get it and are eager to think about the architectural side of the networked apps they work on/with. And then there are those who just want to code / get things done. I can't be angry about the latter ones. But thinking more about architectural implications would bring us forward in the long term.
Whenever I use or write an OpenAPI/Swagger definition, my heart breaks. At least it gets work done. But that's also the reason why I personally still prefer good old server-side rendered HTML with progressive enhancement. There is so much overhead involved in defining some arbitrary HTTP API and then have a UI in some overly complex way. HTML is such a powerful tool to drive the client (the Browser).
Re: Should we rebrand REST?
#47Earlier quoted context omitted.
HATEOAS is somewhat useful even in machine-to-machine: hard-coded URLs in clients are kind of a PITA to support.
To be fair, you need at least one hard-coded URL in your client, don't you? To hit the root entrypoint. And if you have one hard-coded URL... and use it as the root of other URLs, then it's no hard to support than anything. URLs are useful in REST because the API often crosses domain boundaries and company boundaries. One site links to another and so on. Most APIs are not like that. In fact they're only like that whe…
If you look at the hydra API example[1] linked by OP, this is exactly what it needs: one entrypoint URL.
If your API only needs a single domain name (as over 99% of the APIs are), clients can just have the base URL encoded in a constant or a configuration file.
What HATEOAS ostensibly gives you is not the ability to painlessly switch domains, but rather to change your entire URL path structure and even the entire schema represented by your REST endpoints.
This feature turns out to be quite useless for most REST clients. Cosmetic changes to URL structure aside, any useful change (in other words - a schema change), will break the client logic, which is still hard-coded to deal with a predefined schema, predefined types of resources and a predefined set of actions that can be performed on each of them.
Roy Fielding accurately notes that a truly "RESTful" app should let the engine of its state be completely driven by the server. In other words the client cannot have any _specific_ logic related to "state transfers".
If your client is not doing this, like a browser does, than what does it have left to gain from implementing HATEOAS? I'm honestly interested in hearing good arguments, since I haven't heard anything that managed to convince me yet.
I've always worked all my API up to level 2 (HTTP Verbs) of the Richardson Maturity model, but I've never felt convinced that HATEOAS is worth the effort. It seems like the majority of HTTP API designers out there have the same opinion.
Re: Should we rebrand REST?
#48Earlier quoted context omitted.
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.
> 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 RE…
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).
Re: Should we rebrand REST?
#49Earlier quoted context omitted.
> How about simply using "BEST Practices"? REST is already an architecture style, nothing more than an a set of guidelines to design interfaces in order to ensure you get specific qualities and operational advantages. These articles with bold statements regarding the need to change buzzwords already miss the whole point to begin with, and provide absolutely nothing of value.
That's kind of my point. "Use BEST Practices" is nothing more than a set of guidelines, a bold statement to ignore the buzzwords and just do what is currently understood to work the best with today's technologies, whatever buzzwords those practices are currently called, which change over time. For example: BEST Practices a couple decades ago said to use XML over HTTP, while BEST Practices today say to use JSON over H…
> That's kind of my point. "Use BEST Practices" is nothing more than a set of guidelines (...)
I think you're missing the whole point.
REST refers to a specific architecture style which comprises a set of very specific design criteria which are explicitly and very clearly specified in a doctoral dissertation.
The term REST is a term that was coined to refer to that very specific set of design criteria once applied as a whole. Not in part, not as a cherry-picked assortment of choices, but as a whole.
So no, the term doesn't apply to a loose set of guidelines which some guy decided to use just because.
It would be like stating you're using HTTP just because you set up a protocol that does request-response and might have support for annotations passed as.key:value pairs resembling headers, buy at the same time had no verbs.
Re: Should we rebrand REST?
#50Earlier quoted context omitted.
HATEOAS is somewhat useful even in machine-to-machine: hard-coded URLs in clients are kind of a PITA to support.
What is the problem with hard-coded URLs? It is certainly simpler than having to extract the URLs from some other request. If they don't change (and they shouldn't!) I don't see the problem.
Well the problem is exactly that they do change sometimes. And having only one hard-coded URL is easier than having twelve of those.
> It is certainly simpler than having to extract the URLs from some other request.
It's not extracted from other request, it's extracted from the response to the original request, and using a field from the local struct is not harder than using a global constant.