Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST vs. GraphQL – A search for evidence on which is better

42papers.com

Post reply on HN
Print view View original

41–50 of 243 posts

Re: REST vs. GraphQL – A search for evidence on which is better

#41

Post by boublepop »

zachrip wrote: post #34
treve wrote: post #29

This paper has a pretty naive understanding of REST. While 'REST' can mean something different depending on who you talk to, I think in the context of a paper we can expect a bit more research. This paper takes a typical query, and just overlays it on a CRUD-style REST endpoint, but it ignores: * REST can definitely be strongly typed. There's OpenAPI, and JSON-Schema. In many instances I think this will work better t…

I think REST is definitely playing catch up here though. A standard gql setup generally comes out of the box with type generation, web playgrounds, etc. Of course it's possible now with REST but I really think that gql helped push the state of the art in this space.

We’ve had these aspects out of the box with oData REST endpoints that have been in production for half a decade.

Re: REST vs. GraphQL – A search for evidence on which is better

#42

Post by t-writescode »

recursivedoubts wrote: post #27
djlewald wrote: post #22

Earlier quoted context omitted.

I am a fan of GraphQL, but what evidence do you have for "REST sans a hypertext was always a mistake"?

REST requires a uniform interface. Hypertext (or media) is that uniform interface. JSON isn't a hypertext. Therefore JSON isn't an appropriate transport for a REST-ful API. I understand that 99% of the internet disagrees with me.

Could you define your terms?

Especially:

  * uniform interface
  * hypertext
And even more especially how JSON does not meet the requirements?

Re: REST vs. GraphQL – A search for evidence on which is better

#43

Post by recursivedoubts »

clusterhacks wrote: post #31
recursivedoubts wrote: post #19

The results are intuitive and in favor of GraphQL, especially as query complexity increases. GraphQL makes loads of sense for modern javascript thick clients: The front end developer is going to want the same thing that a back end developer has: an expressive, general query language. And the API developer should want to give it to them so they aren't dragging their API around all over the place as fiddly UI & applica…

I designed a REST API with a "well-documented" HATEOAS representation (collection+json). The primary requirement was to ensure there was no caller-side language dependency because we had multiple teams that would be calling the API and those teams might use the command line, Python, Ruby, Javascript, etc clients to consume the API results. API adoption was low in the end - teams in the end wanted libraries rather tha…

> Every consumer I heard about simply parsed the JSON bits they wanted from responses and hard-coded URL links in their client apps

Exactly. HATEOAS is for humans:

https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

Re: REST vs. GraphQL – A search for evidence on which is better

#44

Post by GordonS »

the_arun wrote: post #13
rhacker wrote: post #2

Yes, had this discussion on here before. While in REST you can more or less optimize a service to be performant at what it does, the moment there is another service that you need to fetch some additional data, the browser would be required to orchestrate that, which means you're also waiting for the return trip on the first call before you can even get the secondary data. This alone makes REST far less favorable in m…

Regarding decoupling GraphQL from HTTP - do we need this? cause are there plans to use GraphQL on different protocols like raw TCP? Isn't GRPC better for raw TCP? When we are using HTTP, diluting HTTP standards - eg. using POST for both creating & updating, returning HTTP 200 for errors seem to be hacky in GraphQL. I always found REST to be more simple & straight forward. With progression in HTTP itself - HTTP/2, HTT…

Frameworks like WCF (Windows Communication Foundation) used to support different transport level protocols, like TCP, but IMO that discussion is long over, with HTTP the obvious winner. And of course, the overhead is even less these days with HTTP/2.

I find GraphQL not being coupled to HTTP to be a problem, no a benefit - as you say, returning HTTP 200 for everything is just daft.

Re: REST vs. GraphQL – A search for evidence on which is better

#45

Post by steverb »

I'll be honest. I hate GraphQL. It probably makes sense in a world where everyone uses graphQL, but to me it felt like having to learn yet another query language to do what to me seems straightforward using a simple REST api.

I may also be old and cranky and you should probably get off of my lawn.

Re: REST vs. GraphQL – A search for evidence on which is better

#46

Post by IshKebab »

yumraj wrote: post #6

Are there any performance benchmarks comparing REST and GraphQL?

I think they're too different for that to be meaningful. GraphQL lets you do way more in a query, which means you need fewer queries. It would be like comparing PostgreSQL with Redis, or something.

Re: REST vs. GraphQL – A search for evidence on which is better

#47

Post by cratermoon »

treve wrote: post #29

This paper has a pretty naive understanding of REST. While 'REST' can mean something different depending on who you talk to, I think in the context of a paper we can expect a bit more research. This paper takes a typical query, and just overlays it on a CRUD-style REST endpoint, but it ignores: * REST can definitely be strongly typed. There's OpenAPI, and JSON-Schema. In many instances I think this will work better t…

The paper even says, "the avaliability of a type system —expressed as a schema — is one of the key benefits [of GraphQL]".

In other words, as you say, if there's a schema with the REST API, GraphQL loses one of what the authors claim as a key benefit.

Re: REST vs. GraphQL – A search for evidence on which is better

#48

Post by recursivedoubts »

t-writescode wrote: post #42
recursivedoubts wrote: post #27

Earlier quoted context omitted.

REST requires a uniform interface. Hypertext (or media) is that uniform interface. JSON isn't a hypertext. Therefore JSON isn't an appropriate transport for a REST-ful API. I understand that 99% of the internet disagrees with me.

Could you define your terms? Especially: * uniform interface * hypertext And even more especially how JSON does not meet the requirements?

Uniform interface: https://en.wikipedia.org/wiki/Representational_state_transfe...

Hypertext: https://en.wikipedia.org/wiki/Hypertext

JSON is obviously not a native hypertext, any more than plain text or CSV is. You can, of course, embed URLs in it (or any other format) and call it a hypertext. That's usually pointless, as the links will be consumed by code (rather than a human, in the canonical HTML->browser interaction) so if the URLs aren't simply ignored, they will be dealt with generically.

I wrote about this in HATEOAS is for humans:

https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...

Re: REST vs. GraphQL – A search for evidence on which is better

#49

Post by jsjohns2 »

This is a flawed comparison. GraphQL is probably a superior query language. The more salient question is how the complexity of back-end API endpoint implementation differs.

The answer is that it varies widely between ecosystems (i.e. you are going to have a totally different experience developing a GraphQL endpoint in PostGraphile, Graphene, and Apollo)...and the paper doesn't mention which back-end technology was used.

Re: REST vs. GraphQL – A search for evidence on which is better

#50

Post by cratermoon »

Lapsa wrote: post #5

you must construct additional ~pylons~ abstraction layers

Interesting thought because I see GraphQL as removing a layer of abstraction. Instead of modelling the domain activities and abstracting away the storage model, GraphQL can end up just being a way to express a relational model and SQL as JSON. Except it's not as featureful or complete as the real relational system.
Post reply on HN