Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How did REST come to mean the opposite of REST?

htmx.org

Post reply on HN
Print view View original

81–90 of 393 posts

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

#81

Post by shadowgovt »

rrauenza wrote: post #62

I feel like the author has conflated hypertext with html. The REST interface should be self describing, but that can be done in JSON. If you go to Roy Fielding's post... there is a comment where someone asks for clarification, and he responds: > When I say hypertext, I mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user (or automaton)…

In practice, this turns out to be a painful way for a client to access the data; instead of a single fetch to get the relevant information, we're now doing multiple fetches and collating the results client-side. For this kind of data access, I'd recommend either

a) just denormalizing the field contents if you know what the client needs them for

b) supporting GraphQL if you want to support a general-purpose query endpoint

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

#82

Post by derefr »

janci wrote: 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…

> but no sane client will go around and request random server-provided urls to discover what is available

Compare and contrast: what SQL admin GUI clients do to discover the DBMS schema. They essentially spider it.

> Under HATEOAS the client would need to associate the knowledge of resource structure with a particular resource received. A promising identifier for this association would be the resource collection path, i.e. the URL. If the client needs to know the URLs, why have them in the response?

The client does not need to know the URL; the client needs to know how to get to the URL.

Have you ever written a web scraper, for a site that doesn't really enjoy being scraped, and so uses stuff like CSRF protection "synchronizer tokens"? To do/get anything on such a site, you can't just directly go to the thing; you have to start where a real browser would start, and click links / submit forms like a browser would do, to get there.

HATEOAS is the idea that APIs should also work that way: "clicking links" and "submitting forms" from some well-known root resource to get to the API you know about.

As with a scraper, it's the "link text" or the "form field names" — the delivered API — that you're assuming to be stable; not the URL structure.

> Other problems include creating new resource - how the client is supposed to know the structure of to-be created resource, if there is none yet? The client has nothing to request to discover the resource structure and associations.

What do you think HTML forms are, if not descriptions of resource templates? When you GET /foos, why do you think the browser result is a form? It's a description of how to make a foo (and, through the submit attribute, a place to send it to get it made.)

Alternately, compare/contrast what Kubernetes does — exposes its resource schemas as documents, living in the same resource-hierarchy as the documents themselves live.

> Also hypertext does not map well to JSON. In JSON you can not differenciate between data and metadata (i.e. links to other resources)

It's right in the name: in HATEOAS, hypertext is the engine of application state. Hypertext as in, say, HTML. JSON is not hypertext, because it's not text — it's not a markup language like SGML/XML/HTML are.

You realize that HTML is machine-readable, right? That you can respond to an XHR with HTML, and then parse it using the browser (or API client's) HTML parsing capabilities, just like you can receive and parse JSON? That there's nothing stopping you from using a to send tabular data, etc.? And that if you do so, then debugging your API becomes as simple as just visiting the same link the API client is visiting, and seeing the data rendered as HTML in your browser?

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

#84

Post by xcambar »

wwweston wrote: post #75
ocimbote wrote: 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 descriptivist approach has a lot of merits when it comes to language -- to no small extent, words do mean what people think they mean; this is part of what it means for words to have any meaning at all, and when entire cultures let the meaning of a word drift it's hard to figure out what ground to stand on in order to say they're wrong . And yet... right or wrong, something substantial is lost when "literally" fa…

> And yet... right or wrong, something substantial is lost when "literally" fades into a figurative intensifier.

Yes, but wisdom is to avoid to conflate "lost" for "degraded".

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

#85

Post by a3w »

rrauenza wrote: post #62

I feel like the author has conflated hypertext with html. The REST interface should be self describing, but that can be done in JSON. If you go to Roy Fielding's post... there is a comment where someone asks for clarification, and he responds: > When I say hypertext, I mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user (or automaton)…

I found that json-ld, json-hal and other "describe your json" standards were needed to make json human readable-ish. I hate that there are many competing standards and the link syntax feels clumsy. JSON5 for "add comments, allow ES6 features" was perfect for private and in a small team use for a while.

No one seems to listen to the JSON inventor, who said he regrets creating a misnomer name and no successor should use the same naming parts, since it neither dependent on or compatible with JavaScript, nor was it only useful for storing and/or describing objects. (I am paraphrasing from my memory on his reasoning on both points.)

Open API 3 solved that problem for me, transforming JSON-RPC into a documentented API.

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

#86

Post by alecbz »

Frost1x wrote: post #67
stuckinhell wrote: post #8

Software Development is like water filling a container. It's always water but its form takes the shape of its container. After doing this for 15+ years, I tell my junior developers to take it easy on the "proper way" of doing things. It will change, people will argue, and money talks.

I'd like to see a lot more humility on certainty of approach than the absolutism we often see. There's often a handful or more ways to do anything, why is there so much certainty in all contexts of the correct way. The correct way is often best defined by the unique context a given piece of software is developed within. Tradeoffs take into account more than technology alone.

dhh has a talk about this general idea.

Writing software is such a _human_ thing. It has so much more in common with writing than it does with other kinds of engineering.

Most of what we're doing has to do with how to lay things out so that it's clear and easy for other humans (including the humans that write code) to understand, interact with, and modify. Any time you're dealing with humans brains, there's going to be a lot of complex subtlety in terms of what the "best" approach is.

But because it's software "engineering", people think we need to have fairly hard-and-fast rules about the right way to do everything.

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

#87

Post by coffee_beqn »

munk-a wrote: 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.

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

#89

Post by ocimbote »

int_19h wrote: post #76
derefr wrote: post #57

Earlier quoted context omitted.

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?

That's usually a sign that the thing that didn't get a new word is not actually all that useful or interesting.

Highly debatable. A (too quick?) Darwinist perspective would tell us that the original ReST was not fit. And the "new" ReST (aka, JSON-RPC) is more fit.

Fit in its current ecosystem, of course.

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

#90

Post by Barrera »

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 something by studying the REST story.

For one thing, Fielding's writing is not exactly approachable. REST is described in a PhD dissertation that is dense, packed with jargon and footnotes, and almost devoid of graphics or examples. His scarce later writings on REST were not much better.

Others who thought they understood Fielding, but who could write/speak better than him, came along with different ideas. Their ideas stuck and Fielding's didn't because he wrote like an academic and they did not.

The other thing that happened is that the technological ground shifted. To even begin to understand Fielding requires forgetting much or all of what one knows about modern web technologies. Part of that shift is the timing of Fielding's rediscovery with deep frustration over XML/RPC.

Post reply on HN