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

161–170 of 393 posts

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

#161

Post by derefr »

janci wrote: post #126
derefr wrote: post #94

Earlier quoted context omitted.

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

> This is the whole reason for doing HATEOAS. Seems like a premature optimization to me. Building all applications so that they potentially could be distributed over multiple servers. YAGNI.

We're not talking about centrally-developed distributed applications; we're talking about services that tell you to talk to other services. Services that could very well be developed by other people/organizations, years earlier or later. In fact, services that might very well be "plugins", in the sense that those URLs are user-supplied content from the perspective of the API. (Think: permalink URLs from user-supplied RSS feeds, in the responses of an RSS feed-reader API. Or image URLs, hotlinked in an oldschool phpBB forum. Or RDF vCards.)

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

#162

Post by kareemsabri »

tannhaeuser wrote: post #154
kareemsabri wrote: post #91

Earlier quoted context omitted.

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 ad…

The entire point of Fielding's REST was loose coupling - that you don't hard-code interactions/URLs into clients but rather discover actions/links/interaction from representations dynamically, such that the only thing a client must know a priori is a URL. "REST API" practices are criticized because they follow all the rules and brag about eg HTTP response status code semantics and whatnot, but without following HATEO…

I don't think that was the entire point. But who cares? Loose coupling is of little benefit to the client in a client-server pair that are implemented by the same company (which presumably Fielding wasn't picturing). There are other benefits people get from REST. Semantically understandable APIs, handlers that do one thing, predictable interfaces (this is close to as valuable as discoverable imo). I don't really get your point re: casuistry. The implementation of REST as practiced by the industry is largely pragmatic. The article appears to be arguing for REST purity.

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

#163

Post by jdougan »

jrochkind1 wrote: post #105
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 would say "semantic web" is the key technology in an attempt to make that kind of API that doesn't need human intervention. My understanding of the vision is that when all your responses all described using (fielding original) REST API's via RDF, using URI identifiers everywhere -- then a client that has never seen a particular server can still automatically figure out useful things to do with it (per the end-user'…

It doesn't need the full SemWeb treatment to work. All it needs is a reasonable descriptive language such as SIREN [1] along with Web Link Relations list the IETF maintains already.

1. https://github.com/kevinswiber/siren

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

#164

Post by falcolas »

k__ wrote: post #56
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…

This. I read quite much about REST and HATEOAS, and it didn't made any sense to me. Somehow the "magic sauce" was missing. How should a client that doesn't know anything about an API interpret it's meaning? I felt like an idiot. Like there was some high end algorithm or architecture that completely eluded me. But it the end, it probably just meant, HATEOAS is for humans.

I feel almost like there’s an implicit dependency on GAI for interpreting HATEOS properly.

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

#166

Post by derefr »

janci wrote: post #121
derefr wrote: 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.

information_schema only includes standardized information about standard SQL features. It doesn't expose DBMS-specific features like PG's comments; let alone give you not-standardized info on things that are part of the standard, e.g. any DDL-equivalent machine-accessible representation for views or procedures or types or domains. Gathering all of that stuff requires carefully joining five or ten different DBMS-specific tables together. Some of it even requires feature negotiation + graceful degradation.

> Yes. Awful. Do we want all APIs to be like that? Why?

Because then everything other than the well-known root can be changed freely without breaking the client.

Compare-and-contrast: remote object brokers in dynamic languages, e.g. Ruby's https://github.com/ruby/drb. There are module functions that serve as well-known roots to the APIs you're remoting against; but as soon as you get an object handle, everything from that point forward is the result of sending a proxy-object (opaque API) a message, and getting a handle to a new object passed back in return. Where that new object might actually be an object-handle to an object on a different system than the one you first connected to.

If you write a client to talk to such a remote system the way it's intended (i.e. by making OOP-style call-chains, and holding onto object-handles you want to reuse), then there's very little that should be able to break your client library, besides a fundamental change in the semantics of what the remote service delivers. Your client library isn't making assumptions — it's being told what the possibilities are at each step, like a browser is/does.

Also, the other thing you get is: anyone with a web browser can use your API, because your API is, in a certain sense, "a website." Like how anyone can interact with S3 by just visiting the URL of an object.

> HTML is unsuitable for machine-to-machine communication

Who said? Someone back in 2005, when every language in common use didn't have HTML-parsing libraries?

HTML needs conventional microformats to specify the abstract types of otherwise-text data... but so does JSON. JSON gives you text and numbers, but it doesn't give you ADTs like you'd get from e.g. Avro / Protobufs / etc. You still need a schema on top of JSON to get anywhere. So what are you really getting from JSON that you don't get from having your XHR responses be HTML webpage that were designed to be highly machine legible?

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

#168

Post by ClumsyPilot »

zdragnar wrote: post #5
potamic wrote: post #2

Great article. Calling APIs RESTful because they return JSON has always been a peeve of mine. But here's the question though, why do APIs need to be RESTful? What is the need for a client to have no knowledge of the server, if the server can also provide logic that can run on the client. In some sense, one could argue that a service that provides both raw data and client logic to transform raw data to hypermedia, is…

Why should a server limit itself to a single client? At some point, you might want to make a mobile app companion to your site, or you might white-label your services in partnership with another company who will need to use your APIs, or any number of other common scenarios. A hobbyist / small company doesn't need to have RESTful APIs. The whole point is to design them so that they play well with others, and when you…

> you might white-label your services in partnership with another company who will need to use your APIs,

As soon as you have a third party using your API things get another layer of conplexity: do you charge them? Do you rate limit them? if you have several partners, how do you authenticate them? etc.

API gateway solve some of that, and sometimes you dont care, but generally its not as sinple as goving your internal API to people and telling them to go wild

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

#169

Post by Terretta »

recursivedoubts wrote: post #61
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…

I see in your eyes the same fear that would take the heart of me A day may come when the courage of old web developers fails, when we forsake our old, RESTful network architecture and break all bonds of HATEOAS but it is not this day

    javascript fatigue:
    longing for a hypertext
    already in hand

    // haiku FTA
Post reply on HN