How did REST come to mean the opposite of REST? • Hacker News Board

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

#241

Post by masklinn » Tue, Jul 19, 2022, 5:37 AM UTC

treis wrote: post #43

masklinn wrote: post #37

Earlier quoted context omitted.

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

In Fielding’s REST, the exchange is defined in terms of the document contents (the content types). These are what define the interaction both ways, both in terms of data and in terms of navigating the set and interacting with it (think links and forms).

The client necessarily has to know about that. That’s where the coupling happens. Where the coupling doesn’t happen is in things like resource names and locations, as far as Fielding’s thesis was concerned there’s only one location the client needs to know and it’s the root location, everything else can be obtained by navigating the service.

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

#242

Post by charrondev » Tue, Jul 19, 2022, 5:39 AM UTC

bigDinosaur wrote: post #237

eastbound wrote: post #232

Earlier quoted context omitted.

However, anyone who has used HTTP error codes in REST knows to avoid that – Receiving a 404-Not-Found causes hours of debugging and blind poking compared to receiving a 200-OK-{“error”:”Entity not found”}…

Why can't you do a 404 + message?

Yeah that seems the obvious thing. Our 404s say what wasn’t found (a resource; the endpoint, some associated data in the request).

Our 403s describe what permissions precisely the user is missing.

Our 400s describe what is malformed about the request.

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

#243

Post by masklinn » Tue, Jul 19, 2022, 5:49 AM UTC

kareemsabri wrote: post #162

tannhaeuser wrote: post #154

Earlier quoted context omitted.

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…

> I don't think that was the entire point. But who cares?

People who like language to have meaning?

> which presumably Fielding wasn't picturing

Fielding was describing an architectural style. Although there may have been an element of advocacy, at the end of the day whether you used it or not was not his concern.

> The implementation of REST as practiced by the industry is largely pragmatic.

In the same sense that the implementation of airships in Boeing’s 747 is largely pragmatic, except for the part where Boeing doesn’t misscall their plane an airship.

> The article appears to be arguing for REST purity.

Much like saying a serval is not a dog is arguing for dog purity, yes.

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

#244

Post by osigurdson » Tue, Jul 19, 2022, 5:50 AM UTC

I love how our industry likes to use official sounding names like the "Richardson Maturity Model" and the "Liskov Substitution Principle", etc, as if these informal ideas are on the same level as general relativity and quantum electrodynamics. Thanks Uncle Bob and Martin Fowler for your important contributions to science.

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

#245

Post by arein3 » Tue, Jul 19, 2022, 5:50 AM UTC

Interesting, but the cat is out of the bag.

Now REST means JSON (or other data format) over HTTP with respect to the HTTP methods

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

#246

Post by hsn915 » Tue, Jul 19, 2022, 5:51 AM UTC

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…

It's just, why are we calling it "Rest"?

Just call it adhoc RPC with JSON over HTTP.

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

#247

Post by suprfnk » Tue, Jul 19, 2022, 5:56 AM UTC

hsn915 wrote: post #246

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…

It's just, why are we calling it "Rest"? Just call it adhoc RPC with JSON over HTTP.

That's what REST has come to mean.

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

#248

Post by hsn915 » Tue, Jul 19, 2022, 6:00 AM UTC

quickthrower2 wrote: post #208

I never understood this and still don’t. The P in API is programmer’s. Specifically it is a programattic call. REST says you get hyperlinks, which are effectively documentation in the response. Which is nice. But a program isn’t a person it doesn’t need docs in the response. And URL links are not sufficient documentation to use the interface. So I don’t get the REST use case outside of some university AI project wher…

I don't know if you read the article.

REST is a post-hoc description of how the web worked (at the time it was made).

You had web pages with hyptertext content, and that included forms. The forms had fields with names and an "action" destination.

The client (the browser) knows nothing about the server or even its APIs. It just knows how to send an HTTP request with parameters. In the case of forms, those parameters were encoded in the body of a POST request. That's it.

There was no "client side code" that talked to the server.

The "client side" is literally just the browser. Talking to the server is done by the user clicking links and filling forms.

I don't think the article is particularly encouraing you to program this way in 2022. Just telling you that if you are not programming in this way, do not call what you are doing "REST", because it is not.

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

#249

Post by moring » Tue, Jul 19, 2022, 6:00 AM UTC

AtlasBarfed wrote: post #226

jonhohle wrote: post #218

Earlier quoted context omitted.

I’m not sure what the infatuation with HTTP verbs is. RPC allows modeling objects and arbitrary verbs. REST gives you a handful of verbs and punts on data modeling. It always seemed like a step back from an API design perspective. Definitely a battle I lost but never really understood the other side to begin with.

Standardization and a common language. Limits. Well developed error codes. Rpc is a huge footgun. What's annoying about rest is that it is a religion treated as a universal truth. But really, rest is basically crud.

I disagree about well-developed error codes. Examples:

* There is no useful distinction between different kindes of bad requests (syntactically wrong, structurally wrong, not applicable to the data found, etc.)

* Special handling is needed to test if a resource exists -- you cannot just GET it and check for a 404 code because browsers log all 404 as errors, even if it's the "happy path"

* The error codes confuse authentication and authorization

These error codes are useful when there are middle-men (e.g. proxies) that can understand them without having any application-level logic. But for most REST APIs you don't want those in the way, so that point is moot.

My (to be evaluated) opinion is that RPC is underrated because there have been horrible RPC monstrosities in the past, though I'm aware that without any well-done RPC this opinion is useless.

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

#250

Post by mappu » Tue, Jul 19, 2022, 6:02 AM UTC

bigDinosaur wrote: post #237

eastbound wrote: post #232

Earlier quoted context omitted.

However, anyone who has used HTTP error codes in REST knows to avoid that – Receiving a 404-Not-Found causes hours of debugging and blind poking compared to receiving a 200-OK-{“error”:”Entity not found”}…

Why can't you do a 404 + message?

HTTP is just a transport for your RPC. It's an implementation detail. At the HTTP layer, the transport was successful, so a 200 is appropriate.

A 404 would indicate 'not found' at the transport layer e.g. a bad proxy configuration or you didn't hit the right server at all. You definitely wouldn't confuse it with '${my_widget} not found'.