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

291–300 of 393 posts

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

#291

Post by lloydatkinson »

yesco wrote: post #14
iamthepieman wrote: post #4

Earlier quoted context omitted.

Why do so many APIs do that i.e. 200 OK - {"errorCode": 45634, "errorMessage": "you messed up"} Is there a reason that I'm just not aware of? a throwback to SOAP?

The lead for a project I wasn't working on casually informed me they were doing this a few years ago, the reason for it was nothing complicated, they just hated HTTP status codes and believed it was easier to pretend they didn't exist. I mentioned that it was frustrating to work with APIs like that since a bunch of tooling relies on status codes, including the browser network tab but they just told me they didn't car…

That's very much a red flag. Worked with a couple of similar troglodytes that inspired my original "I don't care about REST anymore" comment - most people are doing it wrong.

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

#292

Post by coldtea »

It's because nobody cares what it meant and what the original concept was, and they don't have a use for it (the original concept).

People want and find useful what they do use in practice: the "opposite of REST" REST.

It's just that purists and/or Fielding overestimate the importance of the original REST.

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

#293

Post by codethief »

chazu wrote: post #187
codethief wrote: post #128

Earlier quoted context omitted.

> I disagree that it isn't an API, but that's a definition quibble. I don't understand: An API is an application programming interface, i.e. it is meant to be consumed by other programs. How does that go together with > REST and HATEOAS are for humans ? And how does that go together with the requirements of "no interpretation needed" and therefore "little coupling" between client and server that were mentioned in the…

An API is also the interface used by humans to create programs. When you use a library, you're using its API. This sense of the term API is often lost.

True, but in this sense every code, every library and every API would be "for humans", which renders this distinction rather useless.

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

#294

Post by z9znz »

eterps wrote: post #277
z9znz wrote: post #274

Author says that the json is not self-describing, but the html example is... That's true if "self describing" means "describes html structure". Perhaps modern use of the term REST is officially incorrect, but I think most REST clients really need to understand what they are receiving. How many rest clients merely show the result (as-is) to the human user? No, most clients are themselves programs which need to consume…

> That's true if "self describing" means "describes html structure". > Imaging having to parse out the official REST HTML response to get the balance of the account. It's not the HTML that matters, it could be any self describing format containing hypermedia controls, for example: https://jasonette.com or https://hyperview.org

The article's "good" (HTML) example above this statement is bone stock HTML. The only self-description given is that there are 4 anchors and 3 divs in that response. Any other description would have to be assumed based on text between the tags.

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

#295

Post by afiori »

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…

It is not "If the client knows nothing about the meaning of the responses" but "The client knows nothing about the API end points associated with this data"

This means that if "/api/item/search?filter=xxxxx" returns an array of ids then you don't have to guess that item prices can be fetched by "/api/item/price?id=nnn" but this url (maybe in template form) needs to be provided by either the "/api/item/search?filter=xxxxx" query or another call you have previously executed.

So very similarly to how you click on links on a website. You often have a priori knowledge of the semantic of the website, but you visit the settings page by clicking of the settings link, not by manually going to "website.example/settings".

PS: these links could be provided by a separate endpoint, but this structure is often useful for things like pagination: instead of manually incrementing offsets each paginated reply can include links for next/previous pages and other relevant links. These need not be full URLs also relative URLs, just URL query fragments, or a JSON description of the query would work (together with a template URL from somewhere else)

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

#296

Post by afiori »

vlovich123 wrote: post #238
mywittyname wrote: post #146

Earlier quoted context omitted.

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…

As someone who has implemented S3 (TL for Cloudflare R2) I’ll choose to disagree that the RESTfulness of the S3 API is a resounding success. Just go ahead and try to write the code to route requests. So many features are likely excluded just because Amazon couldn’t figure out how to jam it into HTTP verbiage. So sure. S3 is implemented on top of REST but I’d much rather pick a proper RPC protocol. The only reason to…

Does R2 also exposes an R2 specific interface or does it only offer the S3 compatible interface?

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

#297

Post by krainboltgreene »

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.

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

#298

Post by krainboltgreene »

root_axis wrote: post #207
a3w wrote: post #85

Earlier quoted context omitted.

I found that json-ld, json-hal and other "describe your json" standards were needed to make json human readable-ish. I hate that there are many competing standards and the link syntax feels clumsy. JSON5 for "add comments, allow ES6 features" was perfect for private and in a small team use for a while. No one seems to listen to the JSON inventor, who said he regrets creating a misnomer name and no successor should us…

JSON is syntactically valid JavaScript, why do you say it's not compatible with JavaScript?

Not all JSON is syntactically valid javascript.

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

#299

Post by afiori »

jonhohle wrote: post #218
mywittyname wrote: post #146

Earlier quoted context omitted.

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…

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.

Most people are doing RPC-on-HTTP and call it REST, probably for the better in many ways.

I personally believe that the Verb/Noun/Resource part of rest is perfectly avoidable, while I believe that including URLs/URLs fragment/URLs-like object in responses is good.

HTTP is a very complex message passing transport layer, API should separately use the platform (HTTP caches/proxies/verbs/headers) and its main messaging feature (URL + body); so just set the right headers and verbs (GET/POST are enough) and pipe JSON/whatever around

(obviously this is for APIs, websites need to use the WWW/HTTP/HTML platform, not just the HTTP platform)

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

#300

Post by minusf »

labrador wrote: post #211

There are only two hard things in Computer Science: cache invalidation and naming things -- Phil Karlton A new name is needed for Classic REST. The use of HATEOAS is ugly because it has HATE in the name. Hypermedia Constraint REST is better. Stateless REST. Pure REST. Classic REST. Separation of Concerns REST. Rest 1.0. Hypermedia REST vs JSON REST

... only two ... "and off-by-ones" :)
Post reply on HN