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

351–360 of 393 posts

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

#351

Post by wvenable »

recursivedoubts wrote: post #337
wvenable wrote: post #157

Earlier quoted context omitted.

It's an app builder not a hypermedia client. It's a pretty slight semantic difference but when we're talking about REST APIs for 3rd party clients then hyperview isn't really relevant to the discussion.

I don't see how you can say it isn't a hypermedia client: it is a client that interprets hypermedia, just like the canonical hypermedia client, a web browser. It's not an internet hypermedia client like a browser, with general access to a broad network of different sites/applications, but the core mechanic satisfies REST and the format being transferred is a hypermedia.

Because it's doesn't have general access to a broad network of different sites/applications it's not a hypermedia client. It's a client for a single service that uses hypermedia is an implementation detail.

An HTML client that can only view Facebook is not a browser, it's a Facebook client.

The point of the article is about how REST should contain all the information needed to traverse a service. But hyperview is for a building a single client/server application where the developers always know the entire interface. So that is the way that it's irrelevant to the discussion.

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

#352

Post by bmn__ »

derefr wrote: post #57
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 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?

Already done: "hypermedia"

Does it delight you?

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

#353

Post by NonNefarious »

recursivedoubts wrote: post #346
NonNefarious wrote: post #290

Earlier quoted context omitted.

Actually, in those cases the client is a person; the browser is only the transport mechanism. But indeed we agree on the "for humans" problem. I'm inclined to accept widely-repeated guidelines on technology that I'm just learning, but this is another instance where the fallacy became obvious when it was time to implement something. Kinda like any attempt to use a lot of inheritance in OOP, which is now recognized as…

Would you say that, in this paper, when Fielding says "client", he means "a person"? https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... Or would the browser be the client?

After hastily searching for "client" and reading how it was used in several places, I would NOT say that he means a person.

But I also don't think he's talking about APIs, which is what the semantic debate seems to be about in this thread. I'm not trying to undermine your point; just to clarify that I was still talking about UI vs. API.

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

#354

Post by samus »

jonhohle wrote: post #218
mywittyname wrote: post #146

Earlier quoted context omitted.

People took the useful ideas and tossed the rest. The whole idea of embedding links into the data that describe available operations was not seen as useful, because most web pages already do that . That was not a problem that needed to be solved. But the concept of resource-oriented architectures which leveraged HTTP verbs to act on data with descriptive URIs was extremely useful in an era when interactions with web…

I’m not sure what the infatuation with HTTP verbs is. RPC allows modeling objects and arbitrary verbs. REST gives you a handful of verbs and punts on data modeling. It always seemed like a step back from an API design perspective. Definitely a battle I lost but never really understood the other side to begin with.

HTTP verbs are best understood as describing the style of interaction with the resource:

- GET/HEAD: read-only, cacheable - POST: side-effects, can be repeated, but not idempotent - DELETE: destructive side-effects, idempotent, no real response - PUT: creative side-effects, idempotent, can return the new resource

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

#355

Post by NoGravitas »

Aeolun wrote: post #281
Joeri wrote: post #7

The client knows nothing about the API end points associated with this data, except via URLs and hypermedia controls (links and forms) discoverable within the HTML itself. If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available. If the client kno…

I don’t understand how anyone would ever expect a REST API to work to send information into a system? So far everything I’ve seen in the article is for reading. You’d still need some generalized format for the client to get some form of input schema, and if you send the input schema for every action every time you retrieve a resource, things quickly become very data intensive.

Have you ever filled out an HTML form that was handled server-side? Is you, you've sent data into a REST system.

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

#356

Post by bmn__ »

jakear wrote: post #55
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…

GitHub’s REST api is pretty self discoverable fwiw. It kinda sucks honestly - every request yields pages of response with field after field of totally irrelevant links. Totally unparseable without json formatting and collapsing support, so CURL/wget/etc. via the terminal are painful. See for example the example response for getting an issue: https://docs.github.com/en/rest/issues/issues#get-an-issue And that even has…

> GitHub’s REST api is pretty self discoverable fwiw.

I had a look at the example response to see whether that is true. I give you that there are hyperlinks existing in resources of media type `application/vnd.github+json`, but there is no uniform interface to discover a link. Fielding would disapprove. It's an indication of bad design that a client must hardcode e.g. `labels_url` instead of having a generic reusable way to access a link that works across a multitude of JSON derived media types.

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

#357

Post by bmn__ »

treis wrote: post #308
masklinn wrote: post #241

Earlier quoted context omitted.

In Fielding’s REST, the exchange is defined in terms of the document contents (the content types). These are what define the interaction both ways, both in terms of data and in terms of navigating the set and interacting with it (think links and forms). The client necessarily has to know about that. That’s where the coupling happens. Where the coupling doesn’t happen is in things like resource names and locations, as…

>Where the coupling doesn’t happen is in things like resource names and locations, as far as Fielding’s thesis was concerned there’s only one location the client needs to know and it’s the root location, everything else can be obtained by navigating the service Yeah, any my point is that relies on the client (i.e. a human) being able to understand what the different links mean. A programmatic client can't do that wit…

> A programmatic client can't do that without in someway hard coding the structure of the API.

That's false. Here is the HTML again, augmented with a link relation which by its nature is perfectly understandable to a program.

    deposits
Anyone can coin a link relation on the Web, as long as its identifier is a URI. Tokens are reserved and need to be registered at IANA: https://www.iana.org/assignments/link-relations

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

#358

Post by jgwil2 »

jackling wrote: post #328
jgwil2 wrote: post #180

Earlier quoted context omitted.

It seems like the article is basically calling REST an architecture or set of conventions that well-designed websites should adhere to, leaving APIs in the literal sense of the term basically out of it entirely. I mean, you could write code to parse any structured data, but if it can change anytime (because it's self-documenting?) then I'm not sure why you would bother.

I don't think that's what the article was saying. It was mainly pointing out the way people incorrectly use the term REST. I don't think the author was saying that well-designed websites should adhere to it, but rather sites that say they're REST but have APIs that are not RESTful. An HTML response is able to be parsed and interpreted by the browser, and doesn't need any special client code to interpret its meaning.…

> I'd argue that it's still an API, since it's still parsed, interfaced with by the system.

Yes, HTML is an API that browsers can interface with. But that interface is on an entirely different level of abstraction from the web application itself. When a web developer writes HTML to be sent to a client in response to some request, they are not making any changes to HTML itself, as a language, and so they are not working on that particular API at all. Rather, they are using that API to develop their own application whose purpose is entirely different from the purpose of HTML. The value they add is not related to solving the problem of exchanging and displaying hypertext documents.

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

#359

Post by NoGravitas »

woodweb wrote: post #324
irrational wrote: post #262

Earlier quoted context omitted.

Don’t parse the HTML, just display it. That’s what the browser does best.

What if a mobile application wants to use the API?

REST systems are designed for use with "generic" clients. The generic client for REST systems on the WWW is a browser. There is probably one available for your mobile platform.

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

#360

Post by munk-a »

bmn__ wrote: post #356
jakear wrote: post #55

Earlier quoted context omitted.

GitHub’s REST api is pretty self discoverable fwiw. It kinda sucks honestly - every request yields pages of response with field after field of totally irrelevant links. Totally unparseable without json formatting and collapsing support, so CURL/wget/etc. via the terminal are painful. See for example the example response for getting an issue: https://docs.github.com/en/rest/issues/issues#get-an-issue And that even has…

> GitHub’s REST api is pretty self discoverable fwiw. I had a look at the example response to see whether that is true. I give you that there are hyperlinks existing in resources of media type `application/vnd.github+json`, but there is no uniform interface to discover a link. Fielding would disapprove. It's an indication of bad design that a client must hardcode e.g. `labels_url` instead of having a generic reusable…

Wouldn't any interface to discover links need to be hardcoded? IIRC, REST didn't actually define a unified way to describe where the links existed in the returned document.
Post reply on HN