The current REST API is currently bloated with so much information one seldom needs when using the software as a headless CMS and could be improved in speed relatively. I suggest running with GraphQL.
This would improve speed of API, All developer to query only information needed.
This could be a start. https://github.com/wp-graphql/wp-graphql
What do you folks think?
As a heavy user of the REST API, this proposal intrigues me. I don't know enough about GraphQL to comment, but I do have some questions:
Perhaps my usage is atypical, but I actually use the REST API more for POSTs than for GETs. How does GraphQL measure up then?
I agree that, by default, the REST API serves up much more info than is required. But, if a custom endpoint is used instead, is there really the same problem?
With the REST API, I can use a custom endpoint (or modify a default endpoint) to specify what information is returned. Why is GraphQL better than that?
Would the effect of using GraphQL essentially be to move the code specifying the returned information from the endpoint to the query? If so, why is that better?
To me the biggest issue with the REST API is that all plugins are loaded by default. I currently use the REST Manager plugin to address that. Would this still be an issue with GraphQL?
I'd like to hear the input of others before I say to much on this.
There are already a few requests about the REST API; hopefully it'll be moved to a core plugin. At that point there's no bloat - install WP-GraphQL or activate the REST plugin, whatever suits your purpose.
Generally I'm against adding things to core unless it's going to enhance things for everyone - in exactly the sense that Gutenberg doesn't.
There are 2 main pieces to the WP REST API. The infrastructure used to create endpoints shipped in WordPress 4.4, almost 3 years ago. The basic content endpoints for posts, comments, terms, and users (and meta and settings) shipped in WordPress 4.7, almost 2 years ago.
Removing either of these pieces or moving them to a plugin would break many major plugins and a huge amount of active sites. It would be interesting to try to estimate how many, but I can tell you it's going to be a huge number.
Implementing a GraphQL API is an interesting idea, but due to existing usage, you can't really "upgrade" an API. Once it's released, it's out there, as a contract that its users expect to be supported for a long time.
I think a GraphQL API should be implemented based on the existing REST controller code, to greatly reduce the amount of custom logic needed. I haven't seen a plugin yet that takes this approach, but if we look at this feature request as "add a GraphQL API", a plugin is a great starting point for making this work.
I want to state the huge amount of effort and time that would be involved in this project, mostly around testing and polishing. It took a consistent team of ~5 people around 4 years to develop the REST API, because core WordPress functionality doesn't fit easily into an API-like structure. And, on top of that, GraphQL is a good bit more complicated, both to implement/test and to understand.
Finally, responding to Tim's specific questions above:
_fields
parameter pretty much solves this.I like the idea of having GraphQL in core but I don't think it's possible to replace the existing REST api with GraphQL since many sites are using it and it has been around for a couple of years.
https://github.com/wp-graphql/wp-graphql is a great start of be able to use GraphQL with WordPress and it's gives a good idea of how much work it is to bring GraphQL into WordPress.
Think it would be possible to offer both solutions (instead of upgrading) where GraphQL use the REST API logic.
Only just seen James's comments. Thanks for the explanation!
A Guide to GraphQL in Plain English: https://medium.freecodecamp.org/a-beginners-guide-to-graphql-60e43b0a41f5
REST APIs and GraphQL APIs are useful for different use-cases; one should not be traded for the other.
For those who are not familiar with the reasons why, this guy does an OUTSTANDING job explaining why:
https://blog.goodapi.co/rest-vs-graphql-a-critical-review-5f77392658e7
I think calling it upgrade was misguided and misleading. I can not change the title unfortunately however modern apps are pushing for GraphQL in the stead of the REST API and using ClassicPress as a CMS/backend with tools like JS on the frontend. Is there a way to reconsider this. Or take on the plugin on https://github.com/wp-graphql/wp-graphql
@Laurence if you like, I can edit the title. I would call it "Add a GraphQL API". Does that sound accurate to you?
That would be very helpful
Updated.
I'd like to throw my 2 cents in here. I'd LOVE to see a community driven effort to adapt GQL into WP. However, I fully and strongly advocate against WP-graphql being that integration.
Unfortunately I think this project is essentially unsalvageable, it's insecure, buggy, and not very well-designed.
It'd be great to see a project like this started from scratch, developed by a solid team of people who truly understand WP's core, GQL and can implement it in a way that's solid, safe and adheres strictly to WP's conventions.
I've been reading about GraphQL, and this page https://www.graphiti.dev/guides/why is pretty compelling to me as to why it's not a good way to do an API. This implementation is in Ruby on Rails, and is completely standalone, but the main point is that REST done right can be more like a mixture of the current REST and some QL.
GraphQL should remain as a plugin, not in core.
I think having this as a plugin to start would be good. Here is a good example of GraphQL based on SpaceX: https://api.spacex.land/graphql/