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

281–290 of 393 posts

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

#281

Post by Aeolun »

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 don’t understand how anyone would ever expect a REST API to work to send information into a system? So far everything I’ve seen in the article is for reading.

You’d still need some generalized format for the client to get some form of input schema, and if you send the input schema for every action every time you retrieve a resource, things quickly become very data intensive.

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

#282

Post by jcelerier »

robertlagrant wrote: post #280
irrational wrote: post #265

Earlier quoted context omitted.

Yes, people who use put and delete (and any other verb other than post and get) come off as insufferable bores to me. Heck, you just use GET and it will work fine 99% of the time.

Having GET commonly understood as idempotent is ergonomic.

everything that relies on a "common understanding" from humans or ridiculous things like non-compiler-enforced idioms, programming styles, etc. is bound to fail at some point. the only thing that matters is what the PL / system accepts.

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

#283

Post by robertlagrant »

jcelerier wrote: post #282
robertlagrant wrote: post #280

Earlier quoted context omitted.

Having GET commonly understood as idempotent is ergonomic.

everything that relies on a "common understanding" from humans or ridiculous things like non-compiler-enforced idioms, programming styles, etc. is bound to fail at some point. the only thing that matters is what the PL / system accepts.

Do you think that browsers pre-emptively executing GET requests, or proxies caching GET responses, is a common understanding from humans?

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

#284

Post by Aeolun »

recursivedoubts wrote: post #132
mercutio2 wrote: post #122

Earlier quoted context omitted.

You don’t mention Content-Type anywhere I could find in your post. I don’t think hypermedia is only for humans. You can totally do REST for computers. You’re just supposed to divide knowledge along Content-Type boundaries. It’s true people mostly don’t do this, but it works great when people bother to describe rich Content-Types.

I mention Content-Type in that I think that discussions around it have largely been a distraction from what I consider the core innovation of REST: the uniform interface. I recognize that many of the few people who still talk about REST would disagree with me on that.

You cannot have the uniform interface without the content type, unless you intend to stay strictly theoretical.

Most programmers have zero interest in staying theoretical, and since everyone had shit to do, and nobody felt like making a whole new content type for their applications, we ended up with only the parts that were immediately useful to people being adopted.

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

#285

Post by Aeolun »

SilasX wrote: post #104
recursivedoubts wrote: post #47

Earlier quoted context omitted.

I am the author and I agree with most of what you are saying here, REST and HATEOAS are for humans: https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h... I disagree that it isn't an API, but that's a definition quibble. It is probably more profitable to talk about RESTful systems rather than RESTful APIs, since people think API == machines talking.

That feels like a pretty significant quibble. API stands for “application programming interface”. If you cannot write an application to programmatically interface with it, why would you call it an API? What you and the parent see REST as, should be called an HPAI: “human-poking-around interface”.

You can see the HTML website as a API, just because it’s hard and annoying to interface with it from another application doesn’t mean that you can’t.

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

#286

Post by pacoverdi »

systematical wrote: post #228

Talk about a getting lost in semantics rant. If you want to make your API "RESTful" like this person describes, there is JSON-LD. Most engineers are going to look at all the extra JSON as getting in their way. What was the point of this rant again?

Agree.

> Today, when someone uses the term REST, they are nearly always discussing a JSON-based API using HTTP.

Yup, this is exactly what I do. So what? Maybe that's incorrect naming but most people only care about being able to easily use the API, not whether it is true REST. And not being 100% REST-spirit-compliant does not prevent from using tools like OpenAPI to document it.

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

#287

Post by jcelerier »

robertlagrant wrote: post #283
jcelerier wrote: post #282

Earlier quoted context omitted.

everything that relies on a "common understanding" from humans or ridiculous things like non-compiler-enforced idioms, programming styles, etc. is bound to fail at some point. the only thing that matters is what the PL / system accepts.

Do you think that browsers pre-emptively executing GET requests, or proxies caching GET responses, is a common understanding from humans?

Those are just bugs from engineers who assumed that such a common understanding existed. Bug reports should be filled, that's all.

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

#288

Post by moth-fuzz »

Is there actually an API out there that actually qualifies as RESTful, other than the WWW itself? When you really take the time to consider the spirit of RESTfulness, and the designs and constraints of hypermedia in general, I can't really think of anything other than just... websites on the internet. Or some WWW-like that might not be transferred over HTTP nor use HTML but would be functionally the same regardless (and far less popular).

It seems that trying to build a hypermedia API in the spirit of hypermedia precludes someone actually designing an app with any particularity (themes, layouts, pages, certain requests/responses being valid/invalid, etc.), since it must be so general, the only client application that could qualify is the web browser itself - able to render any HTML document without actually knowing about the document semantically. Because having prior semantic knowledge of the API violates REST. Assuming that, are the 'apps' and APIs one would design then just hypermedia documents? Sounds like web 1.0. Not necessarily a bad thing, really, but REST seems too specific to be meaningful outside of websites, either that or I'm not imaginative enough.

I'm not sure what a 'hypermedia API' looks like that isn't just a web page or a functional equivalent thereof. It seems that either the WWW is the REST reference implementation or REST is simply the architecture of the WWW codified.

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

#289

Post by KronisLV »

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…

> People took the useful ideas and tossed the rest.

Dylan Beattie actually had a great presentation about REST: "The Rest of ReST" https://youtu.be/g8E1B7rTZBI?t=250

I feel like some of the points in that video are really nice and also sadly some of the nicer possibilities of REST have been left underexplored: HATEOAS and resource expansion sounds great, but I've seen them be used very little in the real world.

Nowadays people reach for GraphQL more often and also sometimes shoot themselves in the foot when they need to deal with the more dynamic nature of querying data with it and the added complexity of an entire query language.

That said, it's nice that we get more and more stateless APIs (with JWTs for example), and sometimes we get the ability to add middleware (like additional auth, logging/auditing or caching layers) without altering the apps themselves too much, and honestly working with JSON and HTTP is wonderfully easy, even if not all of the APIs are actually "truly" RESTful.

I still find myself kind of sad that WADL never got big or that there weren't that many machine oriented API spec solutions that would implement a healthy dose of codegen, a bit more than OpenAPI seems to have built around it. Ideally, you could query a remote API and it would tell you everything that you need to build an API client:

  api-client-codegen --spec rest --input https://api.some-app.com/v3/api-description.json --implementation apache-http-client --output some-app-client-v3.jar
But alas, sadly that's not the world we live in and even while we could programmatically generate clients for APIs that change often, a lot of wisdom was lost from SOAP (and something like SoapUI, where you could feed it a WSDL and get a working client, despite SOAP itself being pretty bad).

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

#290

Post by NonNefarious »

recursivedoubts wrote: post #156
NonNefarious wrote: post #138

Earlier quoted context omitted.

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…

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

I assume that a lot of problems are "solved," but continue to be surprised that they aren't. I defined an API using OpenAPI and am now trying to generate code for it and do some prototyping, but the whole ecosystem is a mess and the standard itself is only now shaking off some truly dumb gaffes.

Post reply on HN