How did GraphQL become a popular way to choose what to query from an API? (Are there any other JSON/XML based implementations?)

I think REST API is very lower level, and cannot compare to GraphQL.

Pacharapol Withayasakpunt

Aug 9

I learnt today that there are actually three things or more...

graphql.org/learn/serving-over-http/

What is the difference between HTTP and REST?

Feb 3 '10 Comments: 7 Answers: 12

312

After reading a lot about the differences between REST and SOAP, I got the impression that REST is just another word for HTTP. Can someone explain what functionality REST adds to HTTP?

Note: I'm not looking for a comparison of REST versus SOAP.

Update: Thanks for your answers…

Open Full Question

It feels like GraphQL and REST API are actually apples and oranges.

This seems to be a correct answer.

hasura.io/blog/rest-view-of-graphql/

I have seen (but never tried) OData, which seems to be focused on GET request and querystrings (and of course has URL length limits.)

I think GraphQL is very daring, in that it encourages using POST to query data, which is controversial, when talking about REST API. (It seems to compensate with different caching mechanisms...)

REST API using POST instead of GET

Oct 28 '13 Comments: 6 Answers: 8

74

Let's assume a service offers some funcionality that I can use like this:

GET /service/function?param1=value1&param2=value2

Is it right to say that I can use it with a POST query?

POST /service/function { param1 : value1, param2 : value2 }

Are these two queries the same? Can I use the second…

Open Full Question

Of course, I can use POST requests with a well-defined JSON schema as well, but it probably will never be as secure, nor standardized, as GraphQL...

https://www.howtographql.com/advanced/4-security/

GraphQL is not only for fetching. It can do mutations as well, but why?

https://graphql.org/learn/queries/#mutations

What are you thoughts, knowledge of history, and recommendations?

Comments

[rhymes]

Hi Pacharapol, it seems like (based on the latest few posts) that you're trying to understand better some concepts around API design. Let's see if I can help:

I think REST API is very lower level, and cannot compare to GraphQL.

I think they are two different things and they could actually co-exist in some APIs. Both have pros and cons. In a sense "REST vs GraphQL" doesn't make sense. For more details, much better than I could explain, I suggest you go through Phil Sturgeon's GraphQL vs REST: Overview. His conclusion are apt:

Swapping one false idol for another isn’t going to make the API world a better place.

This is because each have pros and cons and the actual answer to which one is better is "it depends" :-D Like most things in technology.

I have seen (but never tried) OData, which seems to be focused on GET request and querystrings (and of course has URL length limits.)

I'm not familiar with OData but it seems an effort to standardize REST APIs which inherently don't have a common schema. Though I'd argue JSON schema and OpenAPI are probably more popular than OData, I don't have anything to say about it because I'm not familiar with it

I think GraphQL is very daring, in that it encourages using POST to query data, which is controversial, when talking about REST API.

Though technically GraphQL doesn't forbid GET requests, you're very quickly going to hit the max URL length wall, that's why 99.99% of requests are done with POST and the body.

As you correctly mentioned, GraphQL shifts the burden of caching, it's very well explained in the overview above.

Of course, I can use POST requests with a well-defined JSON schema as well, but it probably will never be as secure, nor standardized, as GraphQL...

Why do you say so? GraphQL is not inherently secure. It's just a protocol on top of HTTP. Security is a thing you have to implement on top of any type of HTTP API you decide to use.

GraphQL is not only for fetching. It can do mutations as well, but why?

I think you know the answer here :D A read only API is useful only in some cases, same way you have POST, PUT, PATCH, DELETE in HTTP and not just GET.

[Pacharapol Withayasakpunt]

Thanks for that phil.tech link.

Why do you say so? GraphQL is not inherently secure.

Simply because more research (on pentesting) is being put into it.

But if you directly try to put JSON-serializable query language into Request Body, that is the path to doom.

• MongoDB aggregate
• json-sql

Of course, GraphQL is always limited by the schema, but it is pretty much autogenerated in Gatsby and Hasura.

[rhymes]

Simply because more research (on pentesting) is being put into it.

But GraphQL has nothing in its spec that talks about security. REST is 20 years old and sits on top of a protocol that's well older. GraphQL on top of HTTP is not inherently secure. Same way REST on top of HTTP is not as well.

There's a ton of research on securing HTTP though