I wholeheartedly agree with the majority of this. In my experience “REST” has been like a religion in which hardly anyone either read the founding text or bothered to interpret very much of it. Fielding’s thesis does not require all of what adherents have claimed it does. An API does not a priori need to adhere to any sect of “REST”, though for many use cases it will benefit. For example, a machine-to-machine API might well have verb URLs to execute something. That’s verboten, a sin but not an excommunicating taboo, in “REST”. The torch carriers can get very specific about a great many aspects, too. I find it refreshing when someone makes good use of HTTP in a way that REST would forbid. For example, if memory serves, Elasticsearch’s search API uses a GET verb, appropriate for retrieving, with a request body to provide information that would be super awkward in the URI. This API is not intended for UI usage, so why not do this?<p>User interfaces can very much benefit from strategic adoption of application state transitions modeled via hypermedia-style links, that’s entirely different.<p>How likely is it, however, that even if Roy wrote an article in a major publication and gave talks at conferences about what’s not really REST, the community would change its use of “RESTful”?
This is all pedantry. I don't think I've ever talked to a developer who cares.<p>All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully.<p>You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about.<p>There are bigger problems in the world. No need to keep redefining dirt.<p>If you spend a considerable amount of time pondering such things, it's probably a sign that you need to be growing somewhere else in life and using those skills to enhance your existing ones.<p>Have tires really changed that much in 200 years?
The author suggests that "there's just far too much confusion about what REST means to rescue it" and suggests differentiating APIs in 2 other categories instead, but in my opinion this not only introduces more confusion, but even there doesn't seem to be any constrain that would prevent the same confusion from arising again. There's no library to enforce a certain standard. It's just another set of well-intentioned guidelines.<p>In a few years we would be reading "should we rebrand Hypermedia APIs?" kind of blog posts.
I don't think anyone cares, really. It's a well established name, people knows what it means a REST-style API. It's not perfect, but nothing is, it's good enough. Let's not change its name, what would be the benefit of it?<p>It would only cause even more confusion for no good reason.
No, it does not deserve a rebrand. It owns the ecosystem of shit that it brought about over the last two decades.<p>I cannot tell you how many meetings I've sat through where engineers have wasted time on discussing the RESTiness of a given "API" call, or which verb makes the most sense.<p>Anyway, we're only a couple of years of group think away from adopting something like JSON-RPC and then it's welcome back to 1999 for all.
Can we just stop jerking off about what is and isn't REST and instead just focus on the pros and cons of any given API?<p>RESTfulness is a useful pattern with some clear advantages. Its not a commandment.
The term really is a bit too academic to understand for a lot of people who are unfamiliar with API design, but comes down to fairly simple concepts when explained in plain language.<p>I compare it to how monads have an ivory tower definition (the famous 'A monad is just a monoid in the category of endofunctors!') for mathematicians, but can be explained in practical terms much more helpfully, even if that loses some theory.<p>Years ago I edited the Wikipedia page--it has always been thorny. The trouble is that the definition of REST is so abstract as to be completely meaningless to the average person reading the article.<p>If you hate using your finite lifespan on something useful, read the talk page. You will find this same edit war playing out over 10+ years between the theorists ('a style of client-server stateless API design where resources undergo state transitions') and the realists who (mis-) define it as a HTTP api.<p>Even though the theorists are correct, I think it's important to recognize that Wikipedia is going to be the first source of for literally millions of people. It would be a tragedy to not acknowledge that.
REST is largely over-hyped as an API design. REST fundamentally represents data transfers. No business can be modeled purely as data transfers.<p>CRUD API would be a good name.
"there's just far too much confusion about what REST means to rescue it"<p>No, there is no confusing. REST is exactly what's in Roy Fielding's thesis. Anything as is derived from REST, often with dismal ends. RESTful, RESTlike, RESTish are weasel words designed to say something along the lines of 'It's REST, but with these additions', or 'It's REST, but with these constraints loosened', or a mix of both.<p>I was there at the beginning of SOA in 2004 and SOA then was an amazingly useful concept that worked well. The term SOA was hijacked to mean so many things, often by consultants pitching their version of SOA enablement or training, and at a rapid pace. By 2009 the meaning of SOA was so buzzwordy and clouded that people were trying to invent new terms to refer to the original concept.<p>If someone wants to create a new thing, create a new thing and give attribution to the shoulders you stand on (i.e., ABC is based on REST but is different in these ways..1,2,3).
People really misunderstand REST, at least as in the original thesis.<p>The original thesis was <i>for the web</i>. It was not meant for microservice JSON APIs.<p>And the web <i>is REST</i>. HTTP, built for web, is REST. The REST principles are integrated in HTTP protocol itself, for I think two decades now.<p>The arguments "is this API RESTful" are nonsense.<p>...but yeah the article says the same, now that I actually read it.<p>...now, let's discuss what "agile" means. Or, maybe not.
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" (<a href="https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html" rel="nofollow">https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...</a>), that made the same point but that I didn't understand fully when I read it.
Well-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.<p>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).
Rebranding misses the point, because most people who claim to provide a REST API are actually providing web API that completely misses many of the rest principles.<p>What we need to do is retrain everyone to use the more general term "Web API" and reclaim the term "rest" for architecture and design decision discussions.
For years I have called my APIs "HTTP API" as they usually do not follow the abstract definition of the REST. And because I've seen so many APIs being called REST that barely follow any definition of a sane API.<p>The whole term is used by people as synonym for an API by management and by developers who never took closer look of the definition/paper.<p>I think that the situation is bit like in OOP, TDD and many other things that cause flame wars. When something good ideas come up, people tend to be religious about it. Instead of taking good ideas and utilize them for better solutions, we take things to extreme and fight about tiniest things.
How about simply using "BEST Practices"?<p>The trademark "YOU'VE TRIED THE REST, NOW TRY THE BEST" is officially abandoned, so that's available.<p><a href="https://trademark.trademarkia.com/youve-tried-the-rest-now-try-the-best-85894317.html" rel="nofollow">https://trademark.trademarkia.com/youve-tried-the-rest-now-t...</a>
I've given up on REST and I build all my new APIs with JSON-RPC. <a href="https://www.jsonrpc.org/specification" rel="nofollow">https://www.jsonrpc.org/specification</a> Super simple.<p>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’ve been in GraphQL land for 4-5 years now, and all these discussions about restfulness, Http and other details make me cringe.<p>It feels like watching apes fighting about whether the cylinder goes in the triangle or star-shaped hole. It does not fit! Realize this and move on!<p>Unless your company is only about CRUD (with no JOINs), the Rest model is severely limited or mismatched to your business domain.<p>Just use GraphQL already. It’s actually simple, I promise! Self documenting, introspectable, supports so much code generation and validation tools, etc...<p>I know I’ll get downvoted for saying this, the HN crowd thinks « GraphQL = complicated » for some reason.
> REST is just the coolest thing in web service API design right now, isn't it?<p>Is it? I still make my APIs REST-like, but I think in terms of “coolness”, GraphQL is more appealing to people isn’t it? Personally I reason that in my APIs GraphQL would be extra complexity for no benefit in my specific use-cases so far. And REST-like serves me well. But for me I choose this way because of ergonomics and because it allows me to implement the things I do with about the least amount of complexity. Coolness doesn’t play a part anymore. But if it did I would surely think GraphQL would be more cool.
> Client applications would not need to be hard-coded with any domain-specific knowledge of the server-side APIs they interact with. Instead, they would discover all the available resources and operations dynamically, at runtime. A client application developed for one hypermedia API could be easily forked and modified for another hypermedia-driven web service. And "smart clients", which are capable of consuming any hypermedia API with a common grammar, could become a reality.<p>This is WSDL and WADL, basically, except there's no common grammar to render a usable interface. The only real thing like what is described is a browser.<p>If you want a universal interface, you make a web app, and the browser is the universal UI. Otherwise you just make a crappy console app and a crappy custom protocol using a HTTP API (or if you hate compatibility, simplicity and convenience: gRPC).<p>To answer the poster's question, no, we're not going to rebrand REST. There are tons of improperly used terms that have been around for ages, they do not get rebranded. You just have to make a new thing and give it a new name and hope that it too isn't misused. ("DevOps" is the most glaring example to me, but also add "hacker", "crypto", "web", "cloud", "container", etc)
This is interesting, and I broadly agree with Kieran's complaints about the quasi-REST-lite that passes for web APIs today.<p>Sadly there's not much tooling or guidance around to try and encourage people to do REST properly. It's really not done well at migrating out of academia, as the author points out, and that's starting to look like a missed opportunity for industry. Other comments here seem to tacitly accept that (lots of "Oh well... is what it is.") Everyone's learned to operate within the status quo, but it's quite costly for API consumers to deal with a range of idiosyncratic APIs (and it's bad for providers too: trying to produce something ergonomic and consumable takes significant effort). Hypermedia would make a lot of that cost go away by making APIs inherently discoverable and eliminating all those unique client libraries and boilerplate.<p>(Plug follows)<p>To try and address that and, in the process, nudge the world towards building and using true hypermedia APIs, I and a couple friends started building <a href="https://intertron.dev" rel="nofollow">https://intertron.dev</a> - a mechanism to turn any web API into a proper, hypermedia REST API. Contact us on that page if this is a topic of interest, we'd love to talk. We can let you have a play with the pre-launch version too.
It has been my experience that most programming terms end up being business or marketing driven if they gain much traction. My pet peeve at one time is API. This term contains the word "interface", meaning external code will interface with your code. However, business calls everything an API and it means a unit of software work from their perspective. Probably the goofiest one is AI. When people say they are using AI it doesn't tell me anything. What is a VM? Python, Perl and other interpreted languages are said to run in a VM. Isn't a container a VM? A container is just host OS VM. I remember when VMWare only had host OS VMs until they came out with the Hypervisor VM, ESXi. Docker is a brand of container and both are VMs. The point is that it is human nature that any word that becomes popularized will take on business and marketing purposes. You just have to roll with it unless one is expressly carrying out technical communication, then clarity of definition does matter.
This gets my vote!<p>I've always felt a little silly to have "REST" included in my resume because too many job descriptions mentioned it as a requirement. Once during an interview, I couldn't resist to challenge the interviewer asking me about "RESTful APIs" that I had built in the past, and I explained pretty much the same thing to him. Thankfully, he was quite open to admit that what most people are doing is not REST.
Reminds me of OOP.<p>"Misrepresentation of the REST architecture has spread so far and wide that "REST" has come to be informally understood as a synonym for "HTTP"."<p>Misrepresentation of OOP has spread so far and wide that "OOP" has come to be informally understood as a synonym for using class based languages.
We should rebrand REST to Rest to emphasize that the original meaning is lost and that we just use it as a shorthand for a http like API. When it comes to web it's best to set our standards as low as possible because being right doesn't seem to have any advantage over being wrong wrt adoption.
It makes absolutely no sense to even suggest that REST should be rebranded "HTTP API" or even "hypermedia API" because REST is neither protocol-specific nor is "hypermedia" the only (or even main) design trait.<p>It's like someone who is entirely unfamiliar with REST feels compelled to make bold statements about traits he doesn't fully grasp.