It doesn't really matter what the dissertation says. Because we don't follow dogma. REST has evolved. Whether people understand it or not isn't that important, what matters is the patterns that emerge that people are actually implementing on working applications.
It's just a naming problem where "REST" is used today for APIs that are almost the opposite of what Roy meant by "REST".
It's like the word "literally" being used to mean "not-literally".
Roy's design was about using custom media types, over any protocol, discoverable via hypermedia. Popular design today is to use just application/json, over HTTP, with externally defined URL schemes. There's nothing wrong with that design — use whatever fits you. Perhaps its even fair to say that Roy's design has failed to gain traction (apart from describing HTML with forms), but what Roy described as "REST" is not what is now commonly understood as "REST".
> It's like the word "literally" being used to mean "not-literally".
It's a digression, but I don't believe this is actually a thing.
Certainly, "Literally" is often used in figurative statements. That's different from using it to mean "figuratively".
I think it's a hyperbolic use of the original sense of "literally"; "literally X" often means "so very like X it was almost as if it was literally X but of course you know the use remains figurative".
In much the same way, if someone says "you left me waiting for days" we don't say "days occasionally means minutes"; we say that people exaggerate. I have never seen an example of a statement that would have been understood literally but for the addition of "literally".
Literally came from quoting texts (usually the Bible). In the oldest uses, we are asking if a quote is literal, as in “part of the Bible”. Usage from the original form diverged pretty much immediately to mean both: in the sense of actually happening; and, in a hyperbolic sense. None of the three uses is any more “correct” as the other; all have been part of English for >300 years.
My contention is that there isn't really much divergence. All of these are natural uses of the single sense of "true to the words". True to the words [of the Bible], true to the words [of description that follows], and a hyperbolic use of the latter.
Note that I'm not saying that "literally" is marking hyperbole, but that it is itself being used hyperbolicaly.
All of these are "correct" not because they are separate, established meanings of "literally" but because they are perfectly natural things to do with a word. I would think that this is also why, in an analysis that mistakes this for "divergence", that divergence was pretty much immediate.
I have actually bought into the hypermedia part of REST and I would still agree. The few who use the term REST to describe hypermedia / hateoas are vastly outnumbered by the ones that don't.
It's a distraction, so I no longer call it REST. Words change and discussions about what the word REST should mean is far less interesting than solving API design problems.
What matters is HATEOAS, arguably the starting principle for REST. The whole point of it is that you can follow URLs as links to reach new app states, and discover these dynamically from a page/resource. As in loosely coupled: it's not agreed up-front or out-of-band what's in an URL. What's being practiced instead almost always is that RESTful apps flaunt their "pretty URLs", and advertise these as "API" (making it two wrongs, since it's neither an API nor REST). Squeezing message payloads into URLs only is worth it if you're actually using these URLs in a hypertext context; as a general RPC encoding mechanism URLs make zero engineering sense (have no types, are needlessly/comically limited in capabilities, etc) when your only consumers/producers are programmatic services and clients anyway. What hurts is that so many RESTful apps are using "patterns" dogmatically and in a cargo-cult way, when to me they're just demonstrating they haven't understood the whole concept at all in the first place.
Pretty URLs do not contradict hypermedia designs. They may leak abstraction, but they can be a convenient implementation detail, decoupling access management and routing from processing the request.
REST is a very specific idea about exchanging states of resources rather than sending commands. The idea did not evolve and it is still useful to talk about it and use it the way it was intended.
I stopped using the term REST for anything I've worked on/with years ago. I just call them Web APIs and no one has ever cared beyond that. REST as an idea is still ineresting, REST as a buzzword feels as dated as "Web 2.0" at this point.
I think this really is the correct approach. I have come across so many differing interpretations of what is properly “RESTful” over the years. Even worse, I have found myself in technical discussions where we were more focused on following proper RESTful API principles rather than simply going with what works best for our use case.
I think it’s useful to read and understand the concepts in Fielding’s dissertation. But don’t set out to build a RESTful API. Set out to build the most appropriate API for the problem you are solving, which may or may not involve incorporating various elements from Fielding’s dissertation.
There's a dissertation and thousands of articles(one if which this comments section links to) that go into all the minutiae of a "proper" REST implementation. My comment poses the idea that an understanding of the proper or pure implementation isn't as important as the broad concepts that you are saying define the whole idea of REST. On the crux of the argument, we are in agreement - those academic details don't really matter.
The thing is, nobody can agree on those broad concepts because they are too vague. On every technical interview I’m asking one question „what is REST?“ usually followed by another „how is different from RPC?“ The answers Usually differ so much, that there’s no way to understand what kind of API these people are describing. It’s like in that tale about six blind men, describing an elephant after touching different parts of its body: one said elephant is like a snake, because he touched only the trunk. Another compared it to a tree after touching a leg. And so on.
A similar case would be OOP. The original idea was broader and more dynamic. But OP has a point: the adoption of these things are useful even if they move away from the original core idea. We should revisit these original ideas and perhaps learn again from them. Sometimes there are things that wasn’t adopted, something we missed, that we can now use to solve problems in a more specific context.
No, it wasn't. The original idea of objects in languages like Simula was what you would later find in C++ and Java: A "this" pointer and a vtable, essentially.
Only later did languages like Smalltalk take the "dynamic" part to the extreme, with their "everything is an object" and "procedure calls are messages" philosophy. Those ideas were not adopted broadly, because they aren't good in general, they have severe trade-offs.
Right, I was referring to the ideas around Smalltalk.
Some of them I find quite interesting, not usually discussed, such as dataless programming, where you program against an abstraction. This is very widely considered a good style in OO today. Go and Rust specifically with their interfaces and traits. Another, more subtle one would be Clojure, which seems to be paradox because it is a data driven language on the surface.
Message passing was also more widely adopted in different forms that are not considered/named OO but carry similar semantics.
The everything is an object idea can be found at least to a high degree in dynamic languages like Ruby, Lua and JS.
I agree. Fielding's dissertation was exactly that - an academic dissertation. A lot of what it proposed wasn't even possible given the languages, software, and protocols. What's important now is that there are REST-ful qualities that people understand and agree upon and even more importantly, future specifications like GraphQL are more rigid and more practical. The industry has learned its lesson.
The author mentions SOAP as what REST came out of, but there were really at least two camps - the formal SOAP camp and Wild West of doing it however you want with POST calls. People were frustrated at these extremes. Regardless of the intention, Fielding's dissertation came at the right time and showed us a path that was simpler than SOAP, but more formal than the Wild West method.
It does matter what the dissertation says if it becomes an orthodoxy, and people follow it to the letter as a way of deferring to expert opinion on how to design APIs. Deferring to expert opinion usually is, and always should be, a good plan. Here, it's a little interesting to discuss whether that's the case.
I would say it always should be a good plan to defer to expert rationale but not opinion. I expect my experts to explain the benefits and drawbacks of following best practices not just assert that something is a best practice. When somebody follows my advice without asking why they should, I start to worry they aren't thinking critically and realize that now all the onus is on me to understand whether the shoe actually fits.
Yes, it's evolved into a steaming mess which people still believe is based on some pure idea of what is REST and what isn't, whereas what this article argues, i.e. that we're completely wrong about that, clears up a lot of things for me because if we were really basing this on something that had been fully thought out and fully comprehended and explained why is it that I've spent ten years writing "RESTful" APIs and ever once even heard of Fielding, let alone Fielding's dissertation, and never, ever, ever have I been able to find something which explained what "RESTful" actually means in terms that related to what anybody was actually trying to do with it.
I've been arguing for a while that we should stop pretending. I'm glad I'm not the only one.
> It doesn't really matter what the dissertation says. Because we don't follow dogma. REST has evolved. Whether people understand it or not isn't that important, what matters is the patterns that emerge that people are actually implementing on working applications.
You seem to forget the litany of articles claiming everybody did REST wrong all the time… Yes, it doesn't matter today. We have GraphQL that put an end to that era of complete bullshit.
