Who’s Using the WordPress REST API?

wp-rest-api

Ryan McCue and the WP REST API team are seeking feedback on the project ahead of the API merging into core. McCue invited comments on the post to find out how and where it’s currently being used, in hopes of identifying any roadblocks developers may be facing.

“We’d love to hear feedback from everyone using this, from JS-only developers coming to WP for the first time, through WordPress plugin and theme developers, all the way through to PHP developers not involved with WordPress,” he said.

Comments on the post provide a nice overview of places where the API is already in use in production all over the WordPress development community. A few examples include:

  • Human Made uses the API with client projects, i.e. to create a Node-powered frontend and maintain the familiar WordPress admin.
  • Reactor uses the API to create mobile apps that digest the API themselves.
  • Aesop Interactive uses the API with Lasso and also to power the WP Live Search plugin.
  • A large industrial real estate firm manages its properties via an internal proprietary .NET app with a public-facing site powered by WP. It uses the API to sync property data (in real time) between the internal app and the website so the real estate listings will always be current.
  • Join In, a site organizing volunteers in the UK, used the API to create an embeddable JS widget.
  • Per Soderlind used the WP REST API as a backend for an iOS application for the Norwegian Ministry of Petroleum and Energy.
  • Modern Tribe is building sites that use the REST API to power both Handlebars and full page React templates in themes.

Those are just a small sampling of places where the API is being used to make WordPress more flexible for creating custom solutions. For many who are using the API or hoping to use it, the main hindrance is that it’s not yet in core.

“The biggest issue right now is that the REST API isn’t included in core,” a representative from Ashworth Creative commented. “If we build plugins or a theme that needs to consume data asynchronously, we’d either have to bundle the API and have to maintain it in our repositories as a dependency, or have clients install and maintain it on their own.”

WordPress developer Nate Wright echoed that opinion and is eager to be able to extend it for use in his products, without having to include it as a plugin.

“Put it in core, so that as a plugin developer I can make use of it in my products,” he said. “I built the most popular Restaurant Reservations plugin in the .org repo, and I am eager to add a robust capacity/table management component for it using the REST API and a jQuery/Underscore/Backbone stack.”

Early adopters have the unique opportunity to provide feedback on the REST API and help shape priorities for development. If you are using the API somewhere in the wild, make sure to leave your feedback on McCue’s post to help the team make any necessary changes required before it’s merged into core.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

18 Comments


  1. I would agree with this:

    “The biggest issue right now is that the REST API isn’t included in core,” a representative from Ashworth Creative commented.

    An associate of mine, the owner of a reasonably large WordPress related software house, has a big piece of software already written and waiting to go. It will not be released until it is in core. Having all these beta plugins is of no use commercially, it speaks of adoption being far too risky.

    The BIG issue is security. If it goes into core, there is going to have to be a lot of hardness testing, because even now the teenage trolls of the world are already writing tools to hack it. My guess is that Matt M will see this as the biggest possible risk to the whole WordPress project. If this goes in core and goes south … well, the risk is far too great.

    Report


  2. I’d use it if it was in core.

    Telling users to install another plugin to run your plugin creates a real bad UX.

    Most folks have been ‘forced’ to roll their own APIs while waiting for the fabled JSON API to roll into core.

    Put JSON API in core already…

    Report


  3. I recently used the Rest API in conjunction with Advanced Custom Fields and a plugin to utilize acf through the Rest API as well. We needed a dynamic way for our client to add custom post types that appeared on a Google Map as they were added. Here is the website currently using it: http://findartdoorsrva.org/.

    It was a fairly straightforward process, call the endpoints via an ajax request, loop through the data objects that were created, and then build out objects using the Google Maps api. Now whenever a new door is added or updated, the map data is updated as well. When you click on the door icons, it displays all of the post/acf information.

    All in all it was a really fun project and a perfect opportunity to try out using the api.

    Report


  4. Given all the other background events going on the last few weeks… how long until someone builds their own system that only deals with Rest API, and completely bypasses the GPL? Unless someone wants to argue that requesting resources from, and submitting comments to, a WP site compels Microsoft to release IE under GPL.

    Report


    1. With the REST API, you are simply exchanging information with WP. Some people will say that a theme and/or plugin is the same, but the difference is actually calling PHP functions directly, instead of hitting an endpoint of an external API.

      So while nobody will or should ever say “using the REST API means you are now GPL’d”, it definitely would be a way for someone *cough like Chris Pearson cough* to build out their own application on top of WP but still keep all his own code proprietary. But at that point, you would need to install both WP and your own app, so it would add a bit to the complexity, I suppose.

      Report


      1. Not really hard at all to distribute things together. I’ll happily publish a Grunt task (I’ll even publish it using GPL) that will install your code and install WP via WP-CLI. Its not so much as complex as vanishingly trivial.

        But that’s my whole point. The REST-API makes creating MyBetterClosedPress using all the WP code, without acknowledging WP at all, and completely ignoring Matt’s opinion about GPL.

        Report


      2. Basically, the Rest API turns WordPress into a highly specialized database.

        Report


      3. That’s it, with WP functions galore. A true framework, with automated, solid core updates for the backend. Put it in core.

        Report


      4. I sort of meant for the more standard, non developer user. I don’t doubt any developer can install WP, but I don’t think your regular user would know what to do with a Grunt file…

        Report


  5. One would hope they test the s**t out of this before it goes into production side by side with the core WP.

    I have found some creative uses so far but it would be nice if wordpress sites turned into apis for other consumers. I can think of some interesting ideas come from that. Also, I can envision some abuses. :/

    Report


  6. echo this
    “The biggest issue right now is that the REST API isn’t included in core,”

    The WP REST API has been in development now for over 2 years now https://github.com/WP-API/WP-API/commits/develop?page=70

    Over that time there has been 56 developers have made 2,244 commits.

    @rmccue has done an enormous amount of work as the lead dev.

    There was talk at one stage that it would be merged to core in wp v3.9 and hopes for every version since including v4.3 … but still not.

    WooCommerce got tired of waiting and released their own in feb 2014 – despite requests from wp to not release theirs until after the WP REST API was released in the core. The WC guys must have known that it was at that stage a long way off happening and went ahead anyway.

    Last year we have built a number of WooCommerce child plugins with utilizing jQuery/Underscore/Backbone stack. couple of them
    http://a3rev.com/shop/woocommerce-predictive-search/
    http://a3rev.com/shop/woocommerce-carousel-slider/

    But have not proceeded with any WordPress integrations because as David Wells wrote

    “Telling users to install another plugin to run your plugin creates a real bad UX.”

    Re what Trevor Nelmes wrote:

    “The BIG issue is security.”

    Whilst it is a top priority as it is with all software – The WordPress https://wordpress.org/plugins/json-rest-api/ has 10,000+ active users, which is a wonderful Beta – stable and seemingly secure

    The WC JSON REST API which had a much shorter development cycle than the WP API is having has been in the wild for 18 months and is active on over 1 million sites without incident (sure their have been a couple of patches for disclosed vulnerabilities but nothing major)

    My wish is that Matt and the Automattic team would make the WP REST API a much higher priority than what I think are peripheral features like the Customizer / shortstack / which seems to be the number 1 priorities.

    Report


  7. First, I think the Live Search is one of the neatest WP things I’ve seen in a couple years. I love playing with it, and it was the first tool I’d seen that I had a reason to install the REST API plugin for.

    Second, I noticed they’ve put a second version of the REST API plugin (and listed it as beta) that’s only compatible with WP 4.3beta and higher…. but I haven’t yet found any explanation on why the split.

    So the original plugin is only “verified” through WP 4.1.6, and the new one only operates on WP 4.3 and higher… leaving every WP 4.2 in an “unofficial” state? Yes, I know the original still works on WP 4.2, but this kinda goes towards the gaps in documentation issues all across the WP spectrum.

    Report


    1. I’m pretty sure “second version of the REST API plugin” on WordPress.org’s plugin repo (https://en-ca.wordpress.org/plugins/rest-api/) is the newer-but-unstable version. It has a lot of improvements but isn’t compatible with the earlier version. It’s what they’re hoping to put in WP core. I think they put it on wordpress.org to encourage folks to test it and get more feedback (also why they posted about this)

      Report


  8. Does the delay into core have to do with the fact that wordpress.com has such an api already and it’s a unique selling point for that platform?

    Report


    1. In a different discussion on a different site, I mentioned that other decisions that have been made which suggest this sort of bias in decision making. For example, if you submit a theme to WP.org, then you cannot include any functionality but this is a feature of VIP themes.

      I was assured that (in that case, at least) its a matter of the uniqueness of the VIP hosting situation and not because allowing only VIP themes with functionality receive the blessing of WordPress gives Automattic any advantage over competitors.

      In all things, the wise person asks, “Cui Bono?”

      Report

Comments are closed.