Hacker News new | ask | show | jobs
by masklinn 2937 days ago
That's really nice, but "real REST services" have never really been a thing, because the reality of "real REST services" is, at the end of the day, that they're not very useful or convenient for machines to consume.

REST works in browsers because there's an intelligent agent driving the interaction. For an automated system it's just pointless drudgery and unnecessary extra requests and data. GraphQL basically fixes all the slow bits, by allowing for a single query in which the client specifies exactly what they want, it cuts down drastically on both the number of network round-trips and the size of data retrieved. And at the end of the day, that means it also (by and large) cuts down on server resources, because those extra connections and that extra data to extract & format is not free.

So GraphQL ends up being both more convenient and more efficient than "real REST services", and that's before we even get to the self-documentation from the schema and to graphiql explorers, which are superior to what "real REST services" could (but never did in my experience) (even less so as browsers kept on not supporting anything other than GET and POST) have provided.

1 comments

> because the reality of "real REST services" is, at the end of the day, that they're not very useful or convenient for machines to consume.

Browsers seem to work fine, unless it's just been a tiny human inside my computer this entire time?

Did your browser somehow post this comment on its own, on your behalf, without you being involved in any way?

I'm guessing no, and that's exactly why REST work. The tiny human is not inside the computer, it's sitting between the keyboard and screen, able to (to a very variable extent) intelligently interpret every document's information and react on the fly depending on their whims and needs.

> Did your browser somehow post this comment on its own, on your behalf, without you being involved in any way?

No, but that's not what rest means?

It did accurately figure out that a file was CSS and to pain the DOM, JS is a program and to run it, to automatically display any images of the correct type and not explode when it sees a image of a type it doesn't know about, and it showed me actions I could click.

> No, but that's not what rest means?

It kinda is, if there's no interaction back and forth the entire thing is completely trivial.

> It did accurately figure out that a file was CSS and to pain the DOM, JS is a program and to run it, to automatically display any images of the correct type and not explode when it sees a image of a type it doesn't know about,

Little of which is of any use to two automated systems interacting without human intervention, and the bits which are of use are not hard.

> it showed me actions I could click.

That's the useful bit when working with an API, knowing that an action can be performed and being able to perform that action.

And that's where REST falls down, because at the end of the day it's not very helpful or convenient at programmatically exposing and allowing these interactions for automated systems.

Again, very good when there's an intelligent and flexible meat bag at one end of the interaction, but that's not what APIs are for in colloquial use.