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

61–70 of 393 posts

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

#61

Post by recursivedoubts »

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

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

#62

Post by rrauenza »

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) obtains choices and selects actions. Hypermedia is just an expansion on what text means to include temporal anchors within a media stream; most researchers have dropped the distinction.

> Hypertext does not need to be HTML on a browser. Machines can follow links when they understand the data format and relationship types.

So, to me, a proper format is something like...

id: 1234

url: http://.../1234

name: foo

department: http://.../department/5555

projects: http://.../projects/?user_id=1234

This is hypertext in the sense that I can jump around (even in a browser that renders the urls clickable) to other resources related to this resource.

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

#63

Post by treis »

Marazan wrote: post #52
treis wrote: post #39

Earlier quoted context omitted.

>Especially if you have metrics/alerts that are tracking status codes. This is the point though. As a client I don't want to throw 400 errors. As a server I don't want to throw 500 errors nor some 400 error. As an example, if either client or server sees a spike of 404 errors they want to investigate. When the result of that investigation is "some crawler went haywire" or "a user is trying to access resources that do…

I as a client care about 400s because that means I fucked up. As a server I don't care about 400s because (within constraints) I don't care if my clients have fucked up. Ad a server I care about 500s as that means I've fucked up. As a client I care about 500s only so much as to know if I should give the server a break and try somewhere else. There is rich, important semantic meaning in the status codes.

>I as a client care about 400s because that means I fucked up.

Not necessarily. If the user enters in the wrong CC number and gets a 402 or 422 back then you don't really care.

>As a server I don't care about 400s because (within constraints) I don't care if my clients have fucked up.

Not necessarily. 404s can be caused by your application routing or a bad link you're generating.

>Ad a server I care about 500s as that means I've fucked up.

Not necessarily as 501 and 505 can be expected behavior

>As a client I care about 500s only so much as to know if I should give the server a break and try somewhere else.

This one is pretty safe

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

#64

Post by janci »

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 second issue is vastly underrated. Protocols that cross layer boundaries are source of trouble and require tons of workarounds. Do you remember how FTP does not work well with NATs? It's because it exposes IPs and ports - transport layer concepts on application layer. SIP? The same thing.

With true REST you can build only HTTP APIs, no websockets, no CLIs, no native libraries.

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

#65

Post by xcambar »

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…

Since you have decided to expand beyond tech, I'd like to share a possibly optimistic perspective.

We are instructed to think that progress is a straight line. Without any surprise, it is not. But I like to picture it with a direction nonetheless... upwards. So as it's not a straight line, I see it as a pulse, with its ups and downs, the ups usually being mild and the lows potentially dramatically sharp.

But still somehow going up.

---

On the current and future challenges: I am mortified about what we did and are doing to the planet and horrified to witness the political tensions in Europe (not only the war, because Europe has seen Crimea, the Balkans, and war never stopped after 1945, but now, there are severe risks of expansion). Also, I do not believe in tech as a means to solve our problems, never did, never will.

So maybe my tiny optimistic pulse trending upwards is too candid and naive but at the moment, maybe blind with despair, I hold on to this idea.

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

#66

Post by kelseyfrog »

An earnest answer? Because few people have taken the couple hours(?) and read Roy Fielding's dissertation from start to finish. The biggest likely reason for not doing so is that frankly a bunch of people simply don't care, and why should they. There's very little incentive to do so. In fact, the fewer people that do, the less of an incentive there is - there is no one can call them out on it and they can reap the rewards of calling an API RESTful despite the accuracy of the statement.

Having worked in an organization where people were very familiar with the academic definition of REST, the biggest benefit of being a backend developer was that when client-side folks depended on nonRESTful behavior, we had some authority to back that claim. It gave us leeway in making some optimizations we couldn't have made otherwise, and we got to stick to RFCs to resolve many disputes rather than use organizational power to force someone to break compliance to standards. I suppose it meant that we were often free to bikeshed other aspects of design instead.

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

#67

Post by Frost1x »

stuckinhell wrote: post #8

Software Development is like water filling a container. It's always water but its form takes the shape of its container. After doing this for 15+ years, I tell my junior developers to take it easy on the "proper way" of doing things. It will change, people will argue, and money talks.

I'd like to see a lot more humility on certainty of approach than the absolutism we often see. There's often a handful or more ways to do anything, why is there so much certainty in all contexts of the correct way. The correct way is often best defined by the unique context a given piece of software is developed within. Tradeoffs take into account more than technology alone.

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

#68

Post by danielovichdk »

Seems strange to me that people fight over REST since it is very clearly communicated in the mentioned PhD dissertation.

I fully understand the movement of complexity, historically belonging on the server, shifted just as much on to the client, but that's not a discussion of being restful - it's not restful to have the client determine application state so to speak - the server does that for you.

In the sense of catering multiple clients via an API is of tremendous value but you still moved the complexity on to the client - you cannot argue against that.

I find it fascinating to have at least blobs of state/representation being served without having to fiddle with inner workings of an API and simply rely on the API to give me what I must show the user.

I am in the HATEOES camp, it sit well with me. But that's just me

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

#69

Post by janci »

zozbot234 wrote: post #48
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.

Aaaand we are back to XML. I don't think XML or RDF is particulary bad for APIs, but they are overly complex and that makes them unpopular.

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

#70

Post by mattarm »

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…

By my read of this "REST API" is a near oxymoron. It was never supposed to be an "API" in the sense that a program consumes it. It was originally described as "Representational State Transfer (REST) architectural style for distributed hypermedia systems" with a focus on describing resources in generic ways for consumption by hypermedia systems (not arbitrary programs!).

I think this is most clearly described by two things Fielding wrote (and the original article links to):

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

Post reply on HN