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:
- Here is some info for write operations (“mutations”) using GraphQL: https://graphql.org/learn/queries/#mutations
- Not really a big problem, IMO, and also the
_fields parameter pretty much solves this.
- The basic idea of GraphQL is that you specify exactly the information you need - and the structure you need it in - with the API call. This could include data from multiple built-in endpoints, in any format you want, and it is presumably less work than writing an entire custom endpoint.
- Complex applications often need to perform many REST requests in a sequence, and these would be optimized and combined into fewer GraphQL requests, which could change pretty drastically depending on the state of the application. There are libraries to help with query-building etc, but I’ve yet to see this working (or failing) in the real world, and we should look for some examples.
- This would depend on the API implementation. Disabling plugin loading during REST requests sounds like a separate feature request to me
~ posted by James Nylen