Live data from Hacker News

How did REST come to mean the opposite of REST?

htmx.org

91–100 of 393 posts

Re: How did REST come to mean the opposite of REST?

#91
post #26

The short answer is... the web moved in a different way than expected and the useful portions of rest were preserved while other portions were jettisoned (the biggest one IMO isn't the hypertext portion (JSONs fine, it's fine ) but the self-discoverable portion - I haven't seen a self-discoverable REST API ever in the wild). Unfortunately the name REST was too awesome sounding and short - so we've never had a fork wi…

> the useful portions of rest were preserved while other portions were jettisoned Not even remotely. All portions of rest were jettisoned, and the nice branding got slapped on familiar rpc. Fielding’s rest was never about http-specific concepts, not the verbs, not the status code, and not cute-looking URLs.

I don't think that's true, unless I just don't understand REST at all. Most "RESTful APIs" in the wild I encounter / implement are

- stateless - cacheable - follow client-server architecture - support resource identification in requests - loosely support resource manipulation through representation (with some caveats)

I don't see how it's RPC by any but the most broad interpretation (a function executes at another address space).

Re: How did REST come to mean the opposite of REST?

#92
post #69

Earlier quoted context omitted.

> On the other hand, it does not provide means to describe semantics of the resource properties Yup, wouldn't it be nice to have some sort of standardized framework to describe those resources? You could perhaps call it a Resource Description Framework, or RDF if you like acronyms.

Aaaand we are back to XML. I don't think XML or RDF is particulary bad for APIs, but they are overly complex and that makes them unpopular.

FWIW, JSON-LD allows one to avoid XML but still gain the benefits of RDF, but I hear you about the "complex" part so ultimately it's like the other commenters have said: is it solving a problem your API and userbase has or not?

Re: How did REST come to mean the opposite of REST?

#93
post #57
post #9

I feel old for I have witnessed many of these battles. But I feel that I have seen history. There's nothing wrong in this article, in the sense that everything's correct and right. But it is an old person's battle (figuratively, no offense to the author intended, I'm that old person sometimes). It would be like your grandparents correcting today's authors on their grammar. You may be right historically and normativel…

The thing that confuses me with semantic drift, is that nobody stops at any point to make a word for what the other word used to mean. It's very hard to refer, at this point, to "the thing that people meant when they said REST ~15 years ago." Can't we just come up with another jargon term for that, that isn't being squatted on?

People do try to come up with new terms. I've seen such suggestions blog posts and comment boards.

The issue is getting everyone to agree with your new word or to even recognize the problems of semantics.

Many people also deliberately misuse the existing terms to get advantages. For example, DevOps in your title gives you a higher pay despite often being materially the same as a pure operations role or sys admin.

Re: How did REST come to mean the opposite of REST?

#94
post #64
post #45

Because HATEOAS is stupid for client-server communication. It mandates discoverability of resources, but no sane client will go around and request random server-provided urls to discover what is available. On the other hand, it does not provide means to describe semantics of the resource properties, nor its data type or structure. So the client must have knowledge on the resources structure beforehand. Under HATEOAS…

Cont.: Because using HTTP verbs and status codes is stupid too: - the API is then tied to single "transport" protocol (it is application layer protocol in ISO/OSI but if you are not building a web browser, your application should reside one layer upwards) - it crosses ISO/OSI layer boundaries (exposes URLs in data, uses status codes for application error reporting, uses HTTP headers for pagination etc.) I think the s…

> exposes URLs in data

That's, uh, the point. Without that, it's not "the web." (And yes, properly-structured APIs are part of "the web" — e.g. the first page of your paginated resource can be on one server, while successive pages are on some other archival server.) This is the whole reason for doing HATEOAS: there's no longer a static assumption that you're working against some specific server with a specific schema structure in place. Rather, your API client is surfing the server, just like you're surfing HN right now.

> no websockets

Correct in a nominal sense, but not in any sense 99% of developers would care about. Instead of RPC over websockets, do REST. Instead of subscriptions over websockets, do REST against a subscription resource for the control-plane, and then GET a Server-Sent Events stream for the data-plane. Perfectly HATEOAS compliant — nobody ever said resource-representations have to be finite.

Re: How did REST come to mean the opposite of REST?

#95
post #69

Earlier quoted context omitted.

> On the other hand, it does not provide means to describe semantics of the resource properties Yup, wouldn't it be nice to have some sort of standardized framework to describe those resources? You could perhaps call it a Resource Description Framework, or RDF if you like acronyms.

Aaaand we are back to XML. I don't think XML or RDF is particulary bad for APIs, but they are overly complex and that makes them unpopular.

RDF does not depend on XML. You can use JSON-LD or text-based syntax (N3, TURTLE or extensions thereof) and those are preferred in modern applications.

Re: How did REST come to mean the opposite of REST?

#96
post #90

Several commenters take the position that the distinction doesn't matter. This is "an old person's battle." What matters is getting things done. I'm not so sure. For one thing, it's of both theoretical and practical interest to trace the path of how a technical term comes to mean its opposite over time. If you're in the business of creating technical terms (everyone building technologies is), you might learn somethin…

REST, SCRUM, Agile, etc these are just cargo cults built from temerity (in the blindness sense).

Re: How did REST come to mean the opposite of REST?

#97
post #9

I feel old for I have witnessed many of these battles. But I feel that I have seen history. There's nothing wrong in this article, in the sense that everything's correct and right. But it is an old person's battle (figuratively, no offense to the author intended, I'm that old person sometimes). It would be like your grandparents correcting today's authors on their grammar. You may be right historically and normativel…

Articles like this are good to show how fads and buzzwords in tech take on a life of their own. Hopefully there are some younger devs in this thread who can learn from it.

Us older guys have to do the opposite. As we see these things come and go, we get jaded and start to dismiss new techniques as fads. I shudder to think of how much wasted effort I put into "Enterprise JavaBeans" and "XSL Transforms". Years later, I took a look at React when it first launched, dismissed it as crap because of the mess it made in the DOM back then, and then ignored it. It took me a few years until I realized I was wrong and it was going to stick around.

Re: How did REST come to mean the opposite of REST?

#99
post #92
post #69

Earlier quoted context omitted.

Aaaand we are back to XML. I don't think XML or RDF is particulary bad for APIs, but they are overly complex and that makes them unpopular.

FWIW, JSON-LD allows one to avoid XML but still gain the benefits of RDF, but I hear you about the "complex" part so ultimately it's like the other commenters have said: is it solving a problem your API and userbase has or not?

How is RDF (sans XML) overly "complex"? Much of it falls out quite naturally from the choice of building data interchange on hyperlinks to resources, similar to human-readable hypertext.

Re: How did REST come to mean the opposite of REST?

#100
post #26

The short answer is... the web moved in a different way than expected and the useful portions of rest were preserved while other portions were jettisoned (the biggest one IMO isn't the hypertext portion (JSONs fine, it's fine ) but the self-discoverable portion - I haven't seen a self-discoverable REST API ever in the wild). Unfortunately the name REST was too awesome sounding and short - so we've never had a fork wi…

> a self-discoverable REST API I’ve been writing web services for over a decade and this just seems like a cute idea that is actually almost never at all useful in the real world.

Yep, there's a big gap between what's useful in Ph.D dissertations and what's useful in the business of software.
Post reply on HN