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

341–350 of 393 posts

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

#341

Post by Sohcahtoa82 »

vgel wrote: post #141
dgudkov wrote: post #135

Earlier quoted context omitted.

>Search engines, archival tools, ML dataset collection, browser extensions and more are able to work with hypertext because it's self-describing They only read state but never modify it. So it misses the whole point of interaction with a web resource.

They can: my password manager auto-logs-in for me. Various tools will automatically find and click the "unsubscribe" link on a mailing list website. Scalper bots buy and resell all kinds of products by navigating web stores (unfortunately). etc. Yes, generally it's more dangerous to make destructive actions automatically on a site you don't know the structure of than against an API a human has considered and designed…

> my password manager auto-logs-in for me. Various tools will automatically find and click the "unsubscribe" link on a mailing list website.

Those tools work by making assumptions. For example, your password manager looks for text input fields with the name attribute set to "user", "username", "login", "email", "account", etc. Create a page with a login form, but name the user field some gibberish, and I bet your password manager won't be able to auto-login.

> Scalper bots buy and resell all kinds of products by navigating web stores (unfortunately). etc.

And each of those bots will need to be written for each store. ie, a bot written to scalp products from Amazon won't work on BestBuy.com.

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

#342

Post by kelseyfrog »

wink wrote: post #303
kelseyfrog wrote: post #66

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

I think you're missing a little historical context here, but maybe you were already more experienced back then than I was, for example (which means your bubble was in the know and the unwashed masses weren't). I started making websites in 1998 and earning money with it in 2001ish (that's the year Wikipedia launched) and imho back then it was a lot harder to find the 'correct' way with teaching yourself. I saw REST/RE…

That aligns roughly with my experience. What I mean is that even post 2010 most people haven't read the material and continue to promote weird frankenapis which they call RESTful based on scrap anecdotes or secondhand messageboard info, or hermeneutical readings of other API designs.

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

#343

Post by Sohcahtoa82 »

suprfnk wrote: post #247
hsn915 wrote: post #246

Earlier quoted context omitted.

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.

REST has come to mean non-REST the same way "literally" has come to mean "figuratively".

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

#344

Post by incrudible »

mike256 wrote: post #260
int_19h wrote: post #181

Earlier quoted context omitted.

That's exactly what I meant. The "new REST" appropriated the term because it's what's actually being used. The "old REST" didn't get a new term because it's not actually being used. There are still theoretical discussions around "old REST", but they all have "new REST isn't REST at all" as their core point, so the lack of new terminology is deliberate there.

We use the old REST a lot and call that what you name "new REST" Json-RPC. What's so difficult about naming things what they are? I mean Devs do have some brain. That's why we are able to write cool software. But then why are some of us too stupid to get that REST thing right?

There is already a standard called JSON RPC and it is not RESTful at all. RESTful means you are using HTTP verbs to convey some information. This is a “mostly stupid” idea, but it has caught on. RESTful is an now industry buzzword. So this is what the pragmatics implement.

We may as well have a debate on what object oriented really means before implementing something, but again, the pragmatic will just create a structure that is broadly recognizable as object oriented.

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

#345

Post by eterevsky »

krainboltgreene wrote: post #297
eterevsky wrote: post #256

If you are designing a REST API, please don't follow this author's advice and return HTML instead of JSON. HTML takes much longer to parse and makes the API more fragile. The history did its job: it preserved the most useful features of the original idea (expressing RPCs as URLs in GET and POST requests) and has dropped the unnecessarily complicated bits. What this article is about is a pedantic terminology battle of…

> If you are designing a REST API, please don't follow this author's advice and return HTML instead of JSON. HTML takes much longer to parse and makes the API more fragile. you're describing what a browser does. > has dropped the unnecessarily complicated bits. you're viewing this content from a browser.

What's your point? If something works for the purposes of UI, it doesn't mean it is good for an API.

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

#346

Post by recursivedoubts »

NonNefarious wrote: post #290
recursivedoubts wrote: post #156

Earlier quoted context omitted.

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…

Actually, in those cases the client is a person; the browser is only the transport mechanism. But indeed we agree on the "for humans" problem. I'm inclined to accept widely-repeated guidelines on technology that I'm just learning, but this is another instance where the fallacy became obvious when it was time to implement something. Kinda like any attempt to use a lot of inheritance in OOP, which is now recognized as…

Would you say that, in this paper, when Fielding says "client", he means "a person"?

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

Or would the browser be the client?

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

#347

Post by klodolph »

kortex wrote: post #316
klodolph wrote: post #270

Earlier quoted context omitted.

The way I think of the status codes is as instructions for how a generic HTTP client or proxy should or may behave in response. Any status code which, in practice, does not affect generic client behavior, does not need to be distinguished in the status code (and can instead be distinguished in the body of the response). For example, status 412 can be thought of as "try the transaction over again, your information abo…

> You could go all WebDAV with status 422 for non-syntactic errors, but I am skeptical of its utility. FastAPI uses 422 for "your data is structured wrong for this schema" and it's better than sliced bread. I think the worst part about the 4xx/5xx distinction is that it doesn't really tell you whether the request is failing in a transient or permanent way (or can't tell). It would have been nice to have more leading…

Yes, maybe the distinction would be nice, but I think the existing 4xx and 5xx codes provide a reasonable baseline for building smart clients.

403, 404—log error, maybe retry later. I don’t think there’s a reasonable way for the server to distinguish transient vs permanent failures here.

429—client should back off, throttle requests.

5xx—client should back off, throttle requests.

The big problem here is that from the server side, if you try to figure out whether an error is transient or permanent, you often get the wrong answer. It’s a diabolical problem. The distinction between “failed” and “overloaded” is something that you might figure out in a post-mortem once humans take a look, but while it is happening, I would not expect the two to be distinguished.

What I do want to transmit from server to client are things like:

- Try again at a different URL (307).

- Try again at a different URL, and update your config to point at this other URL (301, 308).

- The request should be authenticated (401). Try again if you can authenticate.

- I understood the request and had the resources to process it, but the request failed (403, 404, 405, 412, etc) due to the system state. Retry if the user asks for it.

- There is something wrong with the request itself (400, 422, etc). This is a bug, get a programmer to look at it.

- Slow down (429). Retry automatically, but not too quickly.

- As above, but take a look at the server or proxy to see if it’s working correctly. (503, 504)

- Go look at the server logs. (500)

As a rule, I would say that any error can be transitory, and I would tend to write clients with the ability to retry any request. Not as a hard rule, just as a tendency. A “permanent” status code isn’t necessarily a statement of fact, but just a belief.

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

#348

Post by recursivedoubts »

Sohcahtoa82 wrote: post #339
recursivedoubts wrote: post #131

Earlier quoted context omitted.

A concrete action I would suggest is splitting your data API out from your hypermedia API: https://htmx.org/essays/hypermedia-apis-vs-data-apis/ Use hypermedia (and, who would have guessed I'd recommend this? something like htmx) to build your web application. Use GraphQL or whatever other nonRESTful technology fits best to build your data API.

Isn't this just server-side rendering, just doing sections of the page rather than the full page? Looks like it's encouraging coming almost full circle back to web 1.0 where all HTML was generated by the server.

Yes.

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

#349

Post by number6 »

ahtihn wrote: post #331
number6 wrote: post #272

Earlier quoted context omitted.

The Webserver Servers a file or an endpoint. This file or endpoint have indeed be found. On this layer the transaction was successful. So if you return 404 on this layer you are saying that whatever file or endpoint you searched is not there. If you ask for a resource at an endpoint that does not exist e.g. via an parameter in the url and return 404 it is not clear if the endpoint does not exist e.g. the endpoint.php…

You're talking about implementation details on thw server side. Why should the client care about that? Why should the error code for /product/foo/thumbnails/123.jpg be different if served with nginx serving a static file or an application server that dynamically generates it based on the product id?

I make a distinction between the file and the endpoint. While 123.jpg can be found or not the thumbnails/123/ API Endpoint has two parts, the Call and the Argument: 123. To be honest... my argument unraveled in my head while writing - yes you have a point there. So I just can say that 404 is unhelpful because it's unspecific.

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

#350

Post by bmn__ »

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…

> It's a list of URLs, which doesn't even indicate what operations they accept.

HTTP does not require a particular media type's representation to indicate the allowed methods. What made you think this should be the case? All popular media types I know either contain a partial indication (e.g. forms in HTML), and otherwise a fallback to GET/HEAD as default is implied or specified.

If a client is unsure, there's always the OPTIONS method and the Allow header.

Post reply on HN