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

41–50 of 393 posts

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

#41

Post by prox »

jaaron wrote: post #33
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…

This is me, 100%. I've seen enough to realize that progress is largely each generation re-thinking and re-mixing the previous generation's problems. Sometimes the remix makes things better, but plenty of times, older generation look at what's being done and says, "wow, you really don't understand what this was originally intended for" and there's a pain in that misunderstanding and inefficiency, watching work get red…

The amount of people that think that insert musician here had this great original song is one of the most encountered fallacies in my daily life and online.

Not only that, people tend to compare in word and concept from the newer song to the older song! “Hey wow this song from 19xx sounds just like this new song I love”

No you fool, your new song sounds like the previous one :P. Causality matters!

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

#42

Post by glic3rinu »

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?

I’ve always thought it might be PHP legacy of returning 200 even on critical errors. AFAIK Slack and FB APIs work like that, and they are, or have been, PHP based…

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

#43

Post by treis »

masklinn wrote: post #37
treis wrote: post #22

Earlier quoted context omitted.

IMHO, they've wildly missed the mark. APIs, as colloquially known, can't be RESTful as they define it because the client systems aren't AI based and can't follow links. To use their example: Account number: 12345 Balance: $100.00 USD Links: deposits withdrawals transfers close-requests I can navigate to that page and because I know English can follow links to my withdrawls and deposits. A computer can't. The client p…

> The client program needs to have an understanding of withdrawl and deposit in order to function. The only way to do that involves coupling the client to the server. Rest never denied that coupling, it defined that coupling at the content-type level.

Can you expand? I don't think I understand.

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

#44

Post by tirpen »

number6 wrote: post #10
iamthepieman wrote: post #4

Earlier quoted context omitted.

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?

Different layers: the call to the api was successful on the transport Layer, thus 200. You messed up something in the business logic or you asked for a resource that's not there. While often you will get a 404, this is wrong: the http call is successful. The endpoint did not vanish. You just asked for something the business end could not deliver. The Protocol is fine with your call.

> While often you will get a 404, this is wrong: the http call is successful. The endpoint did not vanish

According to RFC 7231, status code 404 means that the specified resource wasn't found. Not that the endpoint wasn't fount.

"The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent."

So replying 404 is the correct response.

https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4

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

#45

Post by janci »

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 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.e. the URL.

If the client needs to know the URLs, why have them in the response?

Other problems include creating new resource - how the client is supposed to know the structure of to-be created resource, if there is none yet? The client has nothing to request to discover the resource structure and associations.

Also hypertext does not map well to JSON. In JSON you can not differenciate between data and metadata (i.e. links to other resources). To accomodate, you need to wrap or nest the real data to make side-room for metadata. Then you get ugly and hard to work with JSON responses. It maps pretty good to XML (i.e. metadata attributes or metadata namespace), but understandably nobody wants to work with XML.

And the list goes on and on.

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

#46

Post by dylan604 »

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…

>(JSONs fine, it's fine)

I read this like you're convincing yourself vs the reader.

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

#47

Post by recursivedoubts »

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.

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

#48

Post by zozbot234 »

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…

> On the other hand, it does not provide means to describe semantics of the resource properties

Yup, wouldn't it be nice to have some sort of standardized framework to describe those resources? You could perhaps call it a Resource Description Framework, or RDF if you like acronyms.

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

#49

Post by lbriner »

number6 wrote: post #10
iamthepieman wrote: post #4

Earlier quoted context omitted.

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?

Different layers: the call to the api was successful on the transport Layer, thus 200. You messed up something in the business logic or you asked for a resource that's not there. While often you will get a 404, this is wrong: the http call is successful. The endpoint did not vanish. You just asked for something the business end could not deliver. The Protocol is fine with your call.

@number6 is right. There are all kinds of problems when you use HTTP status codes to represent something that was correct for HTTP but failed business logic. You don't want a tonne of errors logged because someone has violated business logic but otherwise called the API correctly otherwise good luck finding actual errors where you screwed up by deleting an endpoint (actual 404) or where you changed the request model (400) etc.

I'm sure people might disagree with that approach but it is very common and very reasonable.

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

#50

Post by haroldp »

Por que no los dos? You can build a "real" restful API by returning HTML or JSON based on the request's suffix or HTTP-Accept value. Hit it with a web browser and get a nice "home page" that says, "This is my very cool API. Here are links to various endpoints. Make your requests with 'Accept: application/json' header, or end the request path in '.json' to get a JSON response". Delightfully discoverable and self-documenting.
Post reply on HN