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.
I don't think it's because people are offended at the use of the word master, in this case. I think, that it's symbolic. By making a point of getting rid of the word master, you're showing that black lives matter.
Are we going to get rid of every word that a plantation owner ever used to insult the slaves? For words that specifically have no purpose other than conveying hate, I can understand stamping them out. But master has quite a few other meanings, most of which I would think existed before institutionalized slavery of black people existed. Seems a bit unproductive to target it. They had supervisors - should we stop using the word supervisor? What about boss? Or plantation? Could not the entire BDSM culture be considered in the same way, with its themes of bondage and servitude? Somehow I doubt that every time a sub asks a dom to crack a whip over their head they are celebrating slavery. How close does a word have to be to an issue relative to its other usages in order to be considered a symbol of that issue above all else?
It wasn't intended to be. It's an actual question - where does the cutoff point lie for something standing on its own vs it being considered a problematic and irredeemable symbol of an atrocity and how do we define it? How do we differentiate between when someone is an asshole or not?
I came across an example of this the other day after seeing the word used in a historical text for a class [0,1]. I was fairly certain it did not mean what it sounded like it meant so I looked into it. While the word does not have a definition associated with slavery (that I know of) and is thus arguably further away from the issue than the word master, its phonetics are enough for its usage to result in condemnation.
Lives can be ruined, either from an accusation over a misunderstanding or a failure to recognize actual harmful intent. Vagueness creates friction. To solve a problem there needs be a thorough and precise understanding, and when it involves multiple people there also needs to be a sufficiently common definition.
Please keep denunciatory flamewar rhetoric off this site. If you have a substantive point, you should have no trouble expressing it within the site guidelines.
Please don't bring up tired tropes like that one here. It's never going to change, so we're only going to get a tedious flamewar out of it, which indeed you've been perpetuating downthread—which, please don't.
It's not as if we lack for new things to discuss and argue about.
I saw someone make an excellent point, when someone else was asking why we have a black history month in the United States but not a white history month. He said that we don't have a white history month because every month is white history month in the United States.
Why don't we have a Native American history month, or Hispanic? Is it because those races are just like white people, never have to face discrimination? Never have anyone judge them because of how they look?
Welp, guess you're right. There probably isn't a specific month-long celebration for every race, religion, culture, ethnicity, nationality, profession or identity on Earth.
Although California, at least (possibly other states, it's not worth my time to check), and Canada have Muslim appreciation/history months, and Jewish American Heritage month is in May, as is Asian Pacific American Heritage month.
No one's delivered? There were and are plenty of platforms for full apps on the web. All of them require: loading each time or elevated privileges above the normal browser. This is not the reason they haven't taken off. Security isn't the reason either.
It isn't used because it's just not how the suppliers of content nor consumers of the web want to use the web.
If they want a full featured app, they use it. Even with super fast speeds, latency and minimal startup time still make the browser unattractive for this.
Web users and content providers want linkable documents.
I'd argue that the modern browser stack is so good that we see installed apps adopting html/css/js for the presentation layer.
IMHO the word "installed app" shouldn't even exist. What's the use of "installing" an application these days?
Of course this goes hand in hand with an instant start (no dreaded splash screens please), and not having to download gigabytes upon gigabytes of data upfront.
Modern web apps might be bad at this, and browser engines might be bloated, but native apps aren't any better (even heavy web pages still load many times faster than - for instance - starting Visual Studio or Photoshop).
> Most of this isn't a given anymore with software vendors going subscription-only like Adobe's Creative Cloud.
Please stop saying this as if it is in any way acceptable. Some parts of the computing world work like this, but this is not, nor should it ever be, the new normal.
You can still definitely use your computer without resorting to such licensed crapware.
Progressive Web Apps that work in offline mode are still installed when first accessed through the browser; they just don't need to go through the "traditional" method (installer, app store).
"Traditional" applications that are subscription-only are only partially installed, if their full functionality requires always-on connectivity.
Well, Steam is a DRMed game lending platform; content is only stored off-line because there's no practical way for them to do otherwise. If they could get away with streaming games from their servers, they'd happily do it.
What's the issue? There's two that are unavoidable.
The maximum speed of moving data from one physical place to another, moving data from the hard drive to the motherboard and the ram to the cpu/cache is faster than from the internet to a computer. To he speed of light is still noticably slow when you're making round trips to get data.
The other issue is configuration, even if automated, software needs to make decisions about how to deal with different hardware and system differences. This takes time to bootstrap after initial load increase time to usuability or it can be done on the fly slowing down the interactions.
You know there's a difference between what is most likely true and what's provable in court, right? It's perfectly reasonable to see all the facts, many of which aren't permitted to be considered by a jury, and then say, "wow,these laws are messed up, they let the powerful people get away with crimes. We should change that and hold them accountable."
Likewise, it's not logically consistent to say " well, yeah it looks really bad but because a court can't prove it, I'm going to advocate they they are morally innocent. " Moral and legal aren't the same thing.
Correct, but you shouldn't go to jail for immoral behaviour.
> It's perfectly reasonable to see all the facts, many of which aren't permitted to be considered by a jury, and then say, "wow,these laws are messed up, they let the powerful people get away with crimes. We should change that and hold them accountable."
The IRS does this, and it's horrible, but the accountability comes in the form of an increased tax obligation and not jail time.
Going to jail for doing something that was legal, but has become illegal after the fact, isn't something that benefits anyone but the ruling class, and isn't something that I would advocate for.
There's no reason why "figure out what to do next" can't be a concrete task. I set up a daily schedule and I schedule reassessing and specifying more detail into my work.
The anti-visual noise bias has gone too far. You remove boxes, underlines, and understandable cues like arrows, then they remove words and replace them with nonsense icons. Most UIs make no sense.
I agree. I think even touch UIs should have some hints if you can click on something, and if you can click, force press, or long-press.
It would be great if someone could make hover work on touch UIs.
The great 1980's Mac OS UI was really something. You could explore the menus and see what options was available, and those that didn't apply was still there, giving a hint that you should selecting something to make then selectable.
I agree with the idea that there's too much reliance on in-app education, but this post quickly starts snowballing false metaphors into an extreme of a label is bad design.
There is nothing inherently wrong with the link to the inbox saying "inbox"
Users don't know what all your iconography means.
App design isn't just graphic design or industrial design. It's not airport or device design either.
The app has two purposes, the user wants and what the app provider wants. The problems become more challenging when those two parties desires don't match. Making an app that makes it easy to buy something, take a note, edit an image, or share something with people isn't rocket science with modern OSes and Libraries. These choices are central to discussion because metrics started becoming more important than the core use.
Sometimes this makes business sense, like in a social media app where they want you to stay longer after you share. But this isn't only true because it's a crowded market. Sometimes it doesn't, where a sales app loses sales because they try too hard to move people from what people came to buy to another thing (another product, a membership, a extended warranty, a social media share).
I agree that the industrial design metaphors are iffy, for a different reason. SaaS and apps are WAY easier to redistribute than physical goods and structures. In-app education works well as a way to confirm problems and iterate on solutions while en route to "fixing the underlying problem".
The choice between lengthy design cycles to fix core problems and quick fixes via in app education is a false dichotomy. Use both!
Devs using the newest tech at start-ups, hobbies, and in their side work leads to the menegerie of today's Node Microservices Containers (or whatever) becoming tomorrow's Java 8 on Windows 2012.
Interestingly, I work at a medium sized company that is updating existing tech to microservices and the cloud because 5 years later, it seems like those are good investments that return good value in ease of configuration, deployment, etc.
