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

171–180 of 393 posts

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

#171

Post by sytringy05 »

twoodfin wrote: post #21

This article does a disservice to the benefits of “Richardson Maturity Level 2” i.e. “Use REST verbs”. A standard set of methods—with agreed upon semantics—is a huge architectural advantage over arbitrary “kingdom of nouns” RPC. I’d argue that by the time your API is consistently using URLs for all resources and HTTP verbs correctly for all methods to manipulate those resources, you’ve achieved tremendous gains over…

I wholeheartedly agree, which is why hardly anyone ever builds "REST" APIs. It doesn't really add that much to a data API

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

#172

Post by zdragnar »

ClumsyPilot wrote: post #168
zdragnar wrote: post #5

Earlier quoted context omitted.

Why should a server limit itself to a single client? At some point, you might want to make a mobile app companion to your site, or you might white-label your services in partnership with another company who will need to use your APIs, or any number of other common scenarios. A hobbyist / small company doesn't need to have RESTful APIs. The whole point is to design them so that they play well with others, and when you…

> you might white-label your services in partnership with another company who will need to use your APIs, As soon as you have a third party using your API things get another layer of conplexity: do you charge them? Do you rate limit them? if you have several partners, how do you authenticate them? etc. API gateway solve some of that, and sometimes you dont care, but generally its not as sinple as goving your internal…

Of course it isn't that simple- most of the additional challenges you mentioned are business problems, though, not technical, and are generally orthogonal to the actual design of the API.

The biggest hurdle to opening up your API is usually needing to move from a single tenant to a multi-tenant architecture in your database.

Some tenants will have regulatory burdens you need to meet, and your early adopters will likely have a slew of requests that you'll need to decide on- do you risk tailoring your application to their needs with features future clients won't want?

To these last points, I think RESTful architecture helps, rather than hinders, but YMMV.

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

#173

Post by sytringy05 »

This article answers its own question: "The situation is hopeless, but not serious."

REST vs HATEOS vs HTTP API vs Web Service

It's not serious and it doesn't matter that much. If I'm writing an API, I probably want to give people or systems access to my data and services. Missing links will be a mild inconvenience when compared to things like bad naming, inconsistent data structures, confusing error codes or domain complexity.

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

#174

Post by ninkendo »

masklinn wrote: post #36
Sohcahtoa82 wrote: post #34

Earlier quoted context omitted.

I wish I could upvote this 100 times. REST, in its most strict form, feels like it was designed for humans to directly interact with. But this is exceptionally rare. Access will nearly always be done programmatically, at which point a lot of the cruft of REST is unnecessary.

> REST, in its most strict form, feels like it was designed for humans to directly interact with. It was literally extracted from the browser’s interaction model so… kinda?

But browsers already have HTML for this. Links are just tags. POST endpoints are exposed with , etc. Webpages.

Why do we need a separate concept for this thing called REST if it just reduces to hypermedia in the end?

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

#175

Post by cpill »

mattarm wrote: post #70
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 t…

> describing resources in generic ways

the trouble is that HTML is anything but generic. If you've ever tried to write a web scraper that can be used on _any_ webapage you quickly discover that its near impossible. I use to belived that there should be one way to use HTML to describe the page content and the rest should be CSS but gave up as its completely inflexable and the approch has been abandoned for simply describing presentation as this is actually practical. You'd need a HTML structural standard, but that will get mostly ignore (as have most of the W3Cs recommendations on that subject).

As you said "REST" and "RESTful API" are different beast, i guess the "-ful" should be more of an "-ish".

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

#178

Post by checker »

jrochkind1 wrote: post #105
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 would say "semantic web" is the key technology in an attempt to make that kind of API that doesn't need human intervention. My understanding of the vision is that when all your responses all described using (fielding original) REST API's via RDF, using URI identifiers everywhere -- then a client that has never seen a particular server can still automatically figure out useful things to do with it (per the end-user'…

You have a typo, it's HATEOAS (Hypermedia as the Engine of Application State).

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

#180

Post by jgwil2 »

ninkendo wrote: post #174
masklinn wrote: post #36

Earlier quoted context omitted.

> REST, in its most strict form, feels like it was designed for humans to directly interact with. It was literally extracted from the browser’s interaction model so… kinda?

But browsers already have HTML for this. Links are just tags. POST endpoints are exposed with , etc. Webpages. Why do we need a separate concept for this thing called REST if it just reduces to hypermedia in the end?

It seems like the article is basically calling REST an architecture or set of conventions that well-designed websites should adhere to, leaving APIs in the literal sense of the term basically out of it entirely. I mean, you could write code to parse any structured data, but if it can change anytime (because it's self-documenting?) then I'm not sure why you would bother.
Post reply on HN