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

141–150 of 393 posts

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

#141

Post by vgel »

dgudkov wrote: post #135
vgel wrote: post #109

Earlier quoted context omitted.

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

>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 against. But think about it: the design of HTTP / REST makes that possible. If you tried to write a bot that downloaded random Windows apps and clicked random buttons to "scrape" them, you could easily click a "delete all my files" button in a file management app (not even considering malware). In a REST API, that's not really possible by just issuing GET requests. Google can safely GET any random URL on your site with no harm, unless you've made a serious programming error.

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

#142

Post by icedchai »

tirpen wrote: post #44
number6 wrote: post #10

Earlier quoted context omitted.

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

The problem is you can't differentiate between "resource not found" and "we never even got a chance to process the request for a resource" purely by status code. Maybe your upstream reverse proxy got mis-configured. Maybe DNS is broken.

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

#143

Post by mixmastamyk »

treis wrote: post #63
Marazan wrote: post #52

Earlier quoted context omitted.

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

After many years and reading an insightful post by Ned Batchelder I realized it is folly to swallow errors in low level code.

Keep the low-level simple, always throw errors and let the high level code decide what to do. It has the context and hopefully smarts to make the best decision.

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

#144

Post by mdaniel »

zozbot234 wrote: post #99
mdaniel wrote: post #92

Earlier quoted context omitted.

FWIW, JSON-LD allows one to avoid XML but still gain the benefits of RDF, but I hear you about the "complex" part so ultimately it's like the other commenters have said: is it solving a problem your API and userbase has or not?

How is RDF (sans XML) overly "complex"? Much of it falls out quite naturally from the choice of building data interchange on hyperlinks to resources, similar to human-readable hypertext.

Sorry, I didn't mean that I personally find it complex, merely that I've worked in enough "wwwaaah, software is hard, right-click-y, push" organizations to appreciate why GP would use the word complex and would find friction in rolling out a sane data structure

The only leverage I've ever found for using good data structures is when I can demonstrate they solve a "today" pain point, because money/management DGAF about tomorrow anything, and only the tinyest fuck about customer pain so long as the checks clear

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

#145

Post by marcosdumay »

wwweston wrote: post #118
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…

> If the client knows nothing about the meaning of the responses, it cannot do anything with them but show them to a human for interpretation. This is the best counterpoint in this discussion and it deserves a lot of reflection. But that reflection should include the realization that this is what the browser does all the time . Browsers don't have any particular semantic model in their head of what any particular for…

The original requirement is something on the direction of generalizing HTTP into a protocol for transferring all kinds of data with a human representation interlinked.

What would be very interesting, if HTML didn't evolve with the goal of containing all kinds of data with a human representation too. But now it's mostly redundant and people just prefer encoding things in HTML.

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

#146

Post by mywittyname »

jaaron wrote: post #20
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 would suggest a restful api is not made for system-to-system communication, but requires human mediation at every step of the way" Which is exactly what REST was originally designed to do: provide an architecture for the Internet (not your app or service) that allows for humans using software clients to interact with services developed by programmers other than those which developed the clients. It was about…

People took the useful ideas and tossed the rest.

The whole idea of embedding links into the data that describe available operations was not seen as useful, because most web pages already do that. That was not a problem that needed to be solved.

But the concept of resource-oriented architectures which leveraged HTTP verbs to act on data with descriptive URIs was extremely useful in an era when interactions with web servers would look something like POST /common/backend/doActMgt.pl

Books like RESTful Web Services came out in 2007 and focused almost entirely on resource-oriented architecture. There's not really much mention of hypermedia in it. It's mostly about building API endpoints.

It also referenced AWS S3 (wow, S3 is old) a lot and treated it as a reference implementation / proof of concept that the idea works and is scalable.

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

#147

Post by marcosdumay »

wwweston wrote: post #75
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…

The descriptivist approach has a lot of merits when it comes to language -- to no small extent, words do mean what people think they mean; this is part of what it means for words to have any meaning at all, and when entire cultures let the meaning of a word drift it's hard to figure out what ground to stand on in order to say they're wrong . And yet... right or wrong, something substantial is lost when "literally" fa…

This would be a better point if actual REST was something widely used. Then we would have lost a useful word.

But personally, I think I have never seen any actual REST that wasn't just browser-oriented HTML. So using the word for the API pattern is quite ok.

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

#148

Post by forty »

mywittyname wrote: post #146
jaaron wrote: post #20

Earlier quoted context omitted.

> "This would suggest a restful api is not made for system-to-system communication, but requires human mediation at every step of the way" Which is exactly what REST was originally designed to do: provide an architecture for the Internet (not your app or service) that allows for humans using software clients to interact with services developed by programmers other than those which developed the clients. It was about…

People took the useful ideas and tossed the rest. The whole idea of embedding links into the data that describe available operations was not seen as useful, because most web pages already do that . That was not a problem that needed to be solved. But the concept of resource-oriented architectures which leveraged HTTP verbs to act on data with descriptive URIs was extremely useful in an era when interactions with web…

Did you mean: People took the useful ideas and tossed the REST ? ;)

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

#150

Post by wvenable »

recursivedoubts wrote: post #120
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)…

No, I haven't. JSON can be used as a hypermedia, and people have tried this, but it hasn't really worked out very much and the industry trend is against it, towards a more RPC-like approach. I'm using HTML as an example to demonstrate the uniform interface constraint of REST, and showing how this particular JSON (and, I claim with confidence, most extent JSON APIs) do not have a uniform interface. Which is fine: the…

I'm old enough to remember WML which was a mobile non-HTML hypermedia standard. I enjoyed using it but it was obvious putting an HTML browser on a phone was always going to win out.

Hyperview isn't that interesting because it's a non-standard proprietary technology that isn't really "on the web". So you either have something like that, an actual full-featured HTML browser, or have something consuming a fully defined JSON API. It doesn't feel like there's anything interesting about non-HTML user agents on the web. HTML automatically makes them all irrelevant.

Post reply on HN