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

101–110 of 393 posts

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

#101

Post by derefr »

shadowgovt wrote: post #81
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 endp…

REST says nothing about normalization. In fact the opposite — a resource representation in REST is the very same thing as a graph in GraphQL, or a view in SQL: an arbitrary remix of underlying data. REST is meant to be a projected view-model layer for web clients to interact with underlying data through; it's not meant to inform or be strongly bound to the shape of that underlying data.

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

#102

Post by xcambar »

Barrera wrote: post #90

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

I wrote that it is an old person's battle.

And I'd like to clarity that never did I mean that the knowledge and history fueling this so-called battle was meant to the trash.

Quite the opposite actually. As a self-described old person, I much appreciate the historical perspective and the subtleties and the changes the term has seen.

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

#103

Post by mixmastamyk »

jrochkind1 wrote: post #88

This is undated, but I could swear I had read it before years ago! But I can't find an earlier publication, I guess I read a similar thing!

The author writes on the subject somewhat often and includes ideas from earlier posts. This must be the latest version because it had a link to few-day-old HN thread.

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

#104

Post by SilasX »

recursivedoubts wrote: post #47
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 am the author and I agree with most of what you are saying here, REST and HATEOAS are for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... I disagree that it isn't an API, but that's a definition quibble. It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking.

That feels like a pretty significant quibble. API stands for “application programming interface”. If you cannot write an application to programmatically interface with it, why would you call it an API?

What you and the parent see REST as, should be called an HPAI: “human-poking-around interface”.

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

#105

Post by jrochkind1 »

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's commands, expressed to the software in configuration or execution by some UI), solely by understanding enough of the identifiers in use.

You wouldn't need to write new software for each new API or server, even novel servers doing novel things would re-use a lot of the same identifiers, just mixing and matching them in different ways, and the client could still "automatically" make use of them.

I... don't think it's worked out very well. As far as actually getting to that envisioned scenario. I don't think "semantic web" technology is likely to. I am not a fan.

But I think "semantic web" and RDF is where you get when you try to take HATEOS/REST and deal with what you're describing: What do we need to standardize/formalize so the client can know something about the meaning of the response and be able to do something with it other than show it to a human, even for a novel interface? RDF, ostensibly.

The fielding/HATEOS REST, and the origial vision of RDF/semantic web... are deeply aligned technologies, part of the same ideology or vision.

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

#106

Post by tumetab1 »

iamthepieman wrote: post #4
lloydatkinson wrote: post #3

At this point I’ve stopped caring about REST. It’s like agile and scrum where everyone says they are doing it but everyone has their own opinion of what’s correct. As long as there’s an OpenAPI spec, sane API routes, and it uses a format that’s easily consumable with a given ecosystem (so pretty much always JSON anyway), and it doesn’t do anything dumb like return 200OK { error: true } then I’m happy with it. Too muc…

Why do so many APIs do that i.e. 200 OK - {"errorCode": 45634, "errorMessage": "you messed up"} Is there a reason that I'm just not aware of? a throwback to SOAP?

Yes, because error handling is hard.

The standard reply is that people "the industry" did not clearly defined if HTTP is a transport protocol, has the responsibility to delivery business messages, or if it's an application protocol, has the responsibility to define business messages/process. (Even I trying to make the issue clear I can not use good terms.)

The simplest/tired dev way to do it make HTTP just a transport protocol which means HTTP Status Code only mean Transport success/errors. Failed to send request, HTTP 4XX, failed to received response HTTP 5XX. Application server catastrophic failure, HTTP 5XX.

"RESTfull way" - Transport errors can be generated by client library, HTTP status codes. Business erros can be generated by client library, HTTP status and response body JSON content.

It's mess and made worse by those pretending it's easy, not a mess and it's a standard.

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

#107

Post by greenthrow »

We all decided to keep the important principles of REST and drop the HTML responses because HTML is a terrible format for data exchange between automated systems. JSON is much better for this because it has a simpler schema.

This post is very pedantic. Being pedantic is not helpful.

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

#108

Post by recursivedoubts »

SilasX wrote: post #104
recursivedoubts wrote: post #47

Earlier quoted context omitted.

I am the author and I agree with most of what you are saying here, REST and HATEOAS are for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... I disagree that it isn't an API, but that's a definition quibble. It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking.

That feels like a pretty significant quibble. API stands for “application programming interface”. If you cannot write an application to programmatically interface with it, why would you call it an API? What you and the parent see REST as, should be called an HPAI: “human-poking-around interface”.

REST is an application programming interface for RESTful systems, interpreted by RESTful clients (browsers).

Generic Data APIs, and the clients that use them, are different and have different needs.

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

#109

Post by vgel »

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 is incorrect. There are plenty of machines that read the web: web scrapers, and they've fostered a diverse ecosystem of tools. Search engines, archival tools, ML dataset collection, browser extensions and more are able to work with hypertext because it's self-describing. A new site can pop up and Google can index it without knowing if it's a blog, forum, storefront, or some new genre of website that may be invented in 30 years.

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

#110

Post by wwweston »

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 worked more or less for 30 years.

As for what semantics the UA/client is capable of exploring and providing assistance with: who knows what's possible with additional heuristics + machine learning techniques?

> Also hypertext does not map well to JSON... It maps pretty good to XML... understandably nobody wants to work with XML.

I don't understand that, actually. Markup is underrated for data exchange potential these days. JSON is frequently (though not always) somewhat lighter on bandwidth and often briefer to type for the same underlying reasons, but beyond that there's no inherent advantage. It just became the easiest serialization/deserialization story, half out of riding the way that JS won, half out of what it didn't bother to try doing (a lot of the meta/semantics) and so gave devs permission to stop thinking about.

Post reply on HN