Live data from Hacker News

How did REST come to mean the opposite of REST?

htmx.org

321–330 of 393 posts

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

#321
post #121
post #82

Earlier quoted context omitted.

> 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'm not sure if you are agreeing with me or disagreeing. I was answering the original question - why has REST become non-REST: it is not suitable for client-server apps. >Compare and contrast: what SQL admin GUI clients do to discover the DBMS schema. They essentially spider it. Not really, there is information_shema where they get everything they need to know about structure separately from data. > Have you ever wri…

> Not really, there is information_shema where they get everything they need to know about structure separately from data.

But these tables of metadata are accessed as a graph (usually with plenty of cycles, and iteratively by following relations from specific objects of interest) and the result is a "hypertext" (usually presented as tables or as diagrams of objects) of tables, columns, indices, users, grants etc.

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

#322

Earlier quoted context omitted.

Sort of. Verbs are still eschewed so rather than finding a 'book' link, it would be a 'booking' link to which a POST could be made to create a new booking. As a note, "Booking" is a confusing example because while a hotel booking is a noun it at first glance reads as a progressive tense verb.

So instead of a hard coded url it's a hard coded reference to a url? How does it deal with a breaking changing? Say the order of the links changes? It doesn't seem like this works without some out of band information.

They are keyed using rels. You're right, they aren't relying on order; that would be terrible. And yes, JSON doesn't "have" rels. This is worked around by specifying a mimetype which does. Is it turtles all the way down? Yes, but not all turtles are equivalent. You should already be specifying a "Content-Type": application/json, it's not too much to change that to application/vnd.api+json and write a spec somewhere.

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

#323
post #197

Anarchy, it always has been. Everyone has their own ideas about what REST means or what Hypermedia means.

There is an authoritative source of truth here, though, whether or not anyone chooses to listen to him—Roy Fielding defined REST, so his ideas on this matter are, I'd argue, definitionally correct (which is not automatically the same as most useful).

I think the plot that Roy set for us was lost a long time ago. Right or wrong we can let things evolve.

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

#324

If you are designing a REST API, please don't follow this author's advice and return HTML instead of JSON. HTML takes much longer to parse and makes the API more fragile. The history did its job: it preserved the most useful features of the original idea (expressing RPCs as URLs in GET and POST requests) and has dropped the unnecessarily complicated bits. What this article is about is a pedantic terminology battle of…

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?

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

#326
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…

This is a wrong understanding of that point. The HATEOAS model is designed for one thing: clients and servers that are developed independently of each other. This matches how the Web is designed (browsers and servers are not developed together), but does not match how most Web Apps are developed (there is almost universally a single entity controlling both the server and the client(s) for that app). The point of HATE…

How do you know that the specific login page is where you send the username/password? What if the sevrer changes the login flow to be a 2-part process? What if the clone wants to add an extra challenge like TOTP?

The kinds of changes people are interested in are usually related to changing URLs, and those don't seem very valuable to me for the amount of complexity this flow adds. And ironically enough, the "URL changing" part we already have covered in the old system fine, with HTTP Redirect messages.

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

#327
post #20
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…

> "This would suggest a restful api is not made for system-to-system communication, but requires human mediation at every step of the way" Which is exactly what REST was originally designed to do: provide an architecture for the Internet (not your app or service) that allows for humans using software clients to interact with services developed by programmers other than those which developed the clients. It was about…

I agree with everything you said. As a fellow old person, I just wish they'd call them HTTP+JSON as calling them ReSTful obscures one of the core principals of ReST, Hateos.

It may not matter for a ton of "APIs", but there are a number of places within applications that would benefit from this form of decoupling vs the static client knowing what to do with endpoints, so conflated the makes actual ReST hard for engineers to understand and utilize.

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

#328
post #180

Earlier quoted context omitted.

But browsers already have HTML for this. Links are just tags. POST endpoints are exposed with , etc. Webpages. Why do we need a separate concept for this thing called REST if it just reduces to hypermedia in the end?

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. It understands what's a link, and the actions it can perform on it just using the response itself.

I'd argue that it's still an API, since it's still parsed, interfaced with by the system. The major difference is that the interface is uniform.

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

#329

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 allow to leverage existing HTTP mechanisms like caching proxies and content-type negotiation.

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

#330

Earlier quoted context omitted.

It's funny because HATEOAS violations were single-handedly the most common violation made by the client team during my time there. They loved hard coding URLs and willfully ignoring hypermedia.

What do they do if they don’t hard code it? bookHotelUri = listHotelResponse.data.urls[4]; Or listHotelResponse .data.urls.find(u=>u.action===‘book’).url ?

    listHotelResponse.data.urls.find(u=>u.rel===‘booking’).url
Web linking is defined in https://www.rfc-editor.org/rfc/rfc8288.html and that's the basis for using rel as well as a host of other attributes.
Post reply on HN