There’s a renewed push going on right now to try and get what is being termed “content endpoints” into WordPress core with the 4.7 release — which is being led by Helen Hou-Sandí of 10up.
In the first core development meeting of the 4.7 cycle, Helen proposed a series of things that would need to happen to be able to make a new proposal for core inclusion, including identifying existing blockers. In the conversation that ensued, there was a call for feedback from members of the primary REST API development team — Ryan McCue, Rachel Baker, Joe Hoyle, and Daniel Bachhuber — and a call for other folks to step in and help out, either to increase an existing role, or for the first time. Several people did so, and now there’s a sustained effort to get through various items that have thus far prevented the API from core inclusion.
I am actually taking an active part this time around, and am helping serve as a project manager and liaison between API contributors and core.
If you are not caught up on the state of the WordPress REST API, the infrastructure for the API went into WordPress 4.4. Since that time, several prominent plugins are using the infrastructure to create their own REST APIs. And now the feature project (not in core) consists of core endpoints and authentication mechanisms. The four primary endpoints that have been developed are for posts (and other post types), users, comments, and terms. The endpoints didn’t go into 4.5 or 4.6, and it was time to have a frank conversation about what is acceptable for core as an MVP.
The proposal, if the various criteria are met, will hopefully be enough to convince enough stake holders that the REST API is ready and proper for core inclusion, under the mantra of “content endpoints”, rather than waiting for complete coverage that would include what we’re calling “management endpoints.” With the content endpoints, website developers would have tools at their disposal to build websites in whatever programming language they choose, using data from WordPress. Additionally, certain types of applications would also be able to create experiences for managing WordPress content — though not complete WordPress websites the way you could from the WordPress admin.
The primary focus areas for 4.7 are as follows:
- Rigorous testing with 4.6 and trunk
- Identify and resolve quirky issues (like password-protected posts)
- Enable support for meta data in the API
- Enable support for global site options
- Establish a plan for forward compatibility
- Get dedicated review from developers — including security reviews and from non-WordPress developers
- Identify authentication options and their viability for inclusion with 4.7
- Establish and document performance metrics and comparisons to other tools
- Recruit and assign new and excited contributors
- Align documentation with the project as it stands today, to prepare for new people consuming the API for the first time.
That is not an insignificant list, and it’s not comprehensive either. The team working on this has been working from a document that I’m also going to be imminently documenting on Make WordPress.
This is an exciting time for the WordPress REST API. This tool has a great deal of potential for WordPress, but it needs to be done well. If you have any interest in the API, your help and insights are wanted! You can join Chat.WordPress.org in the #core-restapi room to sit in and watch, or jump in to various discussions. Also, if you just want to play with it and report back your experience, that’d also be super helpful.
I’m sure I’ll have more on this project coming soon.
