The WordPress REST API Is One Major Step Closer to Being Merged Into Core

After more than three years of development, the WordPress REST API is one major step closer to getting merged into core. Ryan McCue, a lead contributor to the project, published the first official proposal to merge the API into WordPress. The proposal explains what the REST API is, why it’s needed, an integration plan, and what happens after the merge. The plan is to integrate the API in two stages, infrastructure and endpoints.

Two Part Plan

The infrastructure is the code responsible for routing requests and handling the meta layer of the API, including JSON serialization/deserialization, linking, embedding, and REST best practices. Merging the infrastructure first allows developers to start building upon it and to migrate from existing custom code. The plan is to merge the infrastructure portion of the API in WordPress 4.4.

Endpoints are considered the more complex of the two as they’re responsible for mapping data from the external JSON format to the internal data structures and vice versa. In other words, endpoints are the bridges of communication between WordPress and external applications. To provide more time for core committers to review the code, endpoints will be merged in WordPress 4.5.

Development of the API takes place on GitHub but core WordPress development takes place on Subversion and Trac. When the API is merged into core, it will no longer be developed as a separate project. McCue proposes that the best of GitHub and Trac be integrated so developers comfortable with GitHub can continue to contribute to the project:

Given the team’s experience with GitHub as well as Trac, we can bring the best of both worlds by helping integrate the two. This would also improve contributions to WordPress as a whole, and benefit the whole community. This will be especially important as we encourage more contributions from the wider community (client authors, for example). We think we can make good progress here, and we’d love to try to help improve the process.

Although there’s a GitHub repository for WordPress that’s synced to its Subversion counterpart, it does not accept pull requests. If integrating GitHub and Trac proves to be successful, it could open the door for WordPress to accept pull requests or contributions through GitHub.

The plan to merge the API into core is not finalized and the team needs your comments, questions, and opinions. I encourage you to read the full proposal and the comments as McCue answers additional questions related to the merge. How happy are you to see this merge proposal?

9 Comments


  1. Given the team’s experience with GitHub as well as Trac, we can bring the best of both worlds by helping integrate the two.

    Amen to that. ?

    Report


  2. One can only hope the GitHub/Trac pairing for the API gets used across core. Trac is probably the single biggest barrier to people getting involved in the project.

    Report


    1. Hurray for integrating core and the repository into GitHub. Much, much easier to work with. And every decent coder has a GitHub account and knows how to use it.

      A small step forward for WordPress and a giant step forward for humankind. Or at least wider contribution.

      Report


      1. Can you really call this a “small step” forward? Sounds like a game changer for WordPress :)

        Report


  3. Can anyone explain to me the real significance of the Rest API and why it’s such a big deal? Maybe some real world examples?

    Report


    1. I would encourage you to have a look at http://wp-api.org/ which describes what WP REST API is and why it adds a significant improvement in the platform. But on the most basic level it allows a developer to interact with WordPress via a set of RESTful API.

      That means I can create an application outside of WordPress (one created in JavaScript for example) and using RESTful approach interact with a WordPress installation using the API calls to get, update, etc. just the data I need instead of having to load WordPress in a WordPress template.
      This greatly extends what can be done with WP and it provides a lot of options for developers and designers.

      Report


    2. To expand on what John Teague says:
      You could use WP as the data storage for native apps. Since the data will be more easily retrievable you can then fetch it for anything. You could probably use it to store data in games even (granted, there are probably much better solutions for that use case).

      A more WP applicable use case is the infinite scrolling wall. yes, you can already do that, but with a RESTfull approach you can load your page and then only load new posts when you need to. Or you can load pages without a full page reload, letting you animate the page load inside your site. Essentially everything you want to load, but isn’t shown directly without the user’s interaction can more easily be defered to the point where the user actually wants to see the content.

      The reason the WP REST API is such a big deal is that it marks a change from full page reloads being the standard, to a much more flexible data driven design.

      Report


  4. How happy are you to see this merge proposal?

    VERY! I’m an iOS developer who’s also a WordPress enthusiast. I’ve seen a lot of jobs where the client has a website built on top of WordPress and they want to build mobile apps using their site’s data. This is going to be big for both mobile and WordPress worlds. So excited for this!

    Report


  5. I hope that they include API soon as possible, developers are waiting some years for it.

    Report

Comments are closed.