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.
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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 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:
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'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
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.
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.
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,DELETEin HTTP and not justGET.Thanks for that
phil.techlink.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.
Of course, GraphQL is always limited by the schema, but it is pretty much autogenerated in Gatsby and Hasura.
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