The proposal by the team was to include the 4 content endpoints when they are ready. We had a lengthly overview as to the progress of those endpoints, more details on what we feel is left to be done can be seen at https://github.com/wp-api/wp-api/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.0

Why these endpoints specifically? Because they are co-dependent for the most part. Shipping Posts without support for Taxonomies would not be that useful.

Going for development of all functionality (somewhere around 8-10 total data routes) should not be underestimated. It’s taken somewhere around a year and a half to get the current 4 to where they are now, and that was with 2 years prior art from Version 1.

As someone who has been in the weeds of that implementation for a while now, I cannot over over-stress just how tricky trying to retrofit a consistent, coherent interface on 13 years of organically grown code and ideas can become. I’m looking forward to being part of the writing the implementation for the remaining (and majority) of functionality, however I don’t want to stop users and developers benefitting from what is already being built for another [several] years.

Joe Hoyle — WordPress Contributors Look for a Path Forward for the WP REST API

Hand Built is Daniel Bachhuber, an effective developer with technology leadership you can trust.

How can I help?

Hit me at [email protected] with a short note about what you'd like to do.

My roots are WordPress and publishing, and I love pretty much everything related to web development (architecture, performance, security, etc.). When not working with clients, I also maintain WP-CLI (WordPress' command line interface) and other open source projects.

Want to connect? I'm on Twitter, Github and LinkedIn. Or, sign up for my TinyLetter for periodic newsletters.