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

151–160 of 393 posts

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

#151

Post by recursivedoubts »

wvenable wrote: post #150
recursivedoubts wrote: post #120

Earlier quoted context omitted.

No, I haven't. JSON can be used as a hypermedia, and people have tried this, but it hasn't really worked out very much and the industry trend is against it, towards a more RPC-like approach. I'm using HTML as an example to demonstrate the uniform interface constraint of REST, and showing how this particular JSON (and, I claim with confidence, most extent JSON APIs) do not have a uniform interface. Which is fine: the…

I'm old enough to remember WML which was a mobile non-HTML hypermedia standard. I enjoyed using it but it was obvious putting an HTML browser on a phone was always going to win out. Hyperview isn't that interesting because it's a non-standard proprietary technology that isn't really "on the web". So you either have something like that, an actual full-featured HTML browser, or have something consuming a fully defined…

hyperview is a hypermedia that exposes native mobile features directly within the hypermedia

you wouldn't create an internet out of hyperview-apps, rather it is a way for you, a developer of a mobile application, to get the benefits of a hypermedia approach (e.g. versioning becoming much less of an issue, vs. app-store updates) while not giving up on native mobile behavior

it is open source, and I think it's one of the most innovative uses of hypermedia I've seen in the last decade:

https://github.com/instawork/hyperview

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

#152

Post by wvenable »

wwweston wrote: post #110
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…

> no sane client will go around and request random server-provided urls to discover what is available. "Random" isn't what's supposed to happen. You hit a top level endpoint, and then at that point other endpoints are made manifest, and then the UA/client and the user decide together what the next relevant endpoint is. And this is what happens all the time with the most common client (the browser). Seems to have work…

> And this is what happens all the time with the most common client (the browser).

Right. Any technology that works this way is basically a "browser". You could create a new markup language or data format and a new user agent to consume it. But you'd be re-inventing the wheel.

There may be some use case for that, as opposed to software clients consuming a well defined API, but I haven't seen it yet. The HTML web browser basically depreciated all other browser-like Internet technologies when it came out (remember Gopher) and is even replacing actual desktop software clients. There's no market for alternative hypermedia clients so why are we giving this so much thought.

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

#153

Post by zach_garwood »

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.

Hello, this is the internet, have you heard of us?

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

#154

Post by tannhaeuser »

kareemsabri wrote: post #91
masklinn wrote: post #30

Earlier quoted context omitted.

> 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 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 HATEOAS which is the entire point of it all. I can see why teams implement "REST APIs" - to end pointless architectural meta discussions and get stuff done; and there's practical value in that. But, harsh as it sounds, and I'm apologizing in advance if this is offending to anyone, dealing with colleagues who mindlessly follow REST casuistry feels like working with hopeless rote learners, psychopathic pretenders, or unstable personalities projecting naive, irrational, and premature ideas of craftsmanship into our profession to me.

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

#155

Post by lmm »

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

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…

You know what else crosses ISO/OSI layer boundaries? Switches. But I don't see anyone saying hubbed networks are better.

And realistically how often are you going to change your "transport"? And if you added an abstraction layer would that actually make it any easier? Stuff like SOAP ends up being the inner-platform effect where you reimplement all of HTTP on top of HTTP and actually implementing a new SOAP transport is just as hard as porting your protocol use a second "transport" if you actually needed to (which you probably won't).

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

#156

Post by recursivedoubts »

NonNefarious wrote: post #138
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…

EXACTLY. Regurgitators of the HATEOAS mantra never address this. Instead you get statements like one in this article: "the HTML response "carries along" all the API information necessary to continue interacting with the system directly within itself." No, it doesn't. It's a list of URLs, which doesn't even indicate what operations they accept. The only thing REST supports, according to this philosophy, is a user manu…

I'm the author, and I agree with you: a list of URLs jammed in a JSON response isn't much of a useful hypermedia affordance and, even if it was, what would some code do with it besides passing it on to a human to deal with?

Old web 1.0 applications, however, let you do a lot more than traipse through an API by clicking on stuff: you can send emails, update documents and on an on, all through links and forms. The HTML, in this system, does "carry along" all the API information necessary for the client (the browser) to interact with the resources it is representing. It relies on the human user to select exactly which actions to take, which is why I say "HATEOAS is for Humans", and wrote an article on exactly that.

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

#157

Post by wvenable »

recursivedoubts wrote: post #151
wvenable wrote: post #150

Earlier quoted context omitted.

I'm old enough to remember WML which was a mobile non-HTML hypermedia standard. I enjoyed using it but it was obvious putting an HTML browser on a phone was always going to win out. Hyperview isn't that interesting because it's a non-standard proprietary technology that isn't really "on the web". So you either have something like that, an actual full-featured HTML browser, or have something consuming a fully defined…

hyperview is a hypermedia that exposes native mobile features directly within the hypermedia you wouldn't create an internet out of hyperview-apps, rather it is a way for you, a developer of a mobile application, to get the benefits of a hypermedia approach (e.g. versioning becoming much less of an issue, vs. app-store updates) while not giving up on native mobile behavior it is open source, and I think it's one of t…

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.

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

#160

Post by molbioguy »

forty wrote: post #148
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…

Did you mean: People took the useful ideas and tossed the REST ? ;)

Brilliant!
Post reply on HN