23 Comments


  1. This is fantastic. Having heavily extended the current WordPress XML-RPC API for Spokal’s WordPress integration, I can confirm that it is pretty archaic. Looking forward to having a modern API to work with!

    Reply
    1. lupetalo

      Looks like this plugin here about is copy of another plugin…. Why don’t you give credit to original author and call this fork.

      Reply

  2. @Sarah Gooding -Aha thanks. Trying to figure out which to use. The plugin is extendable with modules to setup any JSON REST call you could imagine.

    I wonder how the flexibility of the new implementation will look.

    Reply

  3. Really excited about this. Props to Ryan for taking this huge steps. There are hell loads of things I can do with. Now we can make use of Backbone.js to create single page application or to keep things faster.

    All the best Ryan :)

    Reply

  4. Together with a new widgets interface, this is one of the features I’m most excited about coming to core! Hope the Pods project will extend this to work with pods data as well. Using WordPress as a self-hosted backend for any kind of app will become very interesting.

    Reply

  5. Does anyone know if there will be a token based system with the new API? Avoiding the need for sending user login details over the wire would be darned handy.

    Reply

  6. Very exciting news for many reasons but just this together with Backbone.js is going to be HUGE for WordPress. Well done Ryan for all your hard work on this!

    Does this mean we will be seeing a WordPress app store anytime soon? ;)

    Reply

  7. @Ryan Hellyer -There isn’t a built-in token-handling method, as that’s firmly plugin territory. However, the authentication system is (of course) pluggable (in fact, it uses WP’s normal authentication, but with an additional handler for HTTP Basic authentication). I happen to have a plugin that does OAuth 1.1, so I might end up releasing a plugin to do this. :)

    @David Gwyer – I happen to be working on a project for just that. ;)

    Thanks to everyone for the kind words, and to Sarah for the interview!

    Reply

  8. @Ryan McCue -You said “that’s firmly plugin territory”. Why is that so? I assumed that a token system would be kinda generic and tie in well with the API itself. The official WordPress mobile apps. in particular could make use of it.

    Reply

  9. @Ryan Hellyer – If we implement a token system, the question then becomes, how do we handle this? We could create our own system, but it seems like a waste to reinvent the wheel, so we’d probably go with an existing system, such as OAuth. I know from experience that OAuth is not exactly trivial to implement (althought OAuth 2 is better), so it would be a fairly heavyweight feature to include in core.

    Not saying it won’t happen, but I suspect it’ll stay in plugin territory for now. That might be reconsidered based on what we as a team decide though.

    Reply

  10. @Ryan McCue -Yeah, it’d need to be oAuth I think. I think it is a worthy goal to pursue, simply so that the official WordPress apps. can connect back to base in a secure fashion.

    Reply
  11. John David

    So, besides the previous plugin already mentioned (json-api), there’s also another plugin also called wp-api (I’m assuming not the same one, as it’s already at version 1.0.3).

    Anybody done any work with either of these existing plugins?

    Reply



  12. Guys this looks like a big improvement. But it’s like all the other Json Apis it’s not really restful.

    When is someone going to do it properly? A user should be able to just use the same urls as to get html, xml, or json versions of all content (based on content negotiation) and if desired also post updates to the same urls.

    That would unlock the true power of rest and wordpress.

    Reply

  13. @Pete – HTML/XML/JSON is not really part of being RESTful, however it’s theoretically possible to do this already. The API only translates to/from JSON in a select few places, so you can serialise it to XML, ZeroMQ, MessagePack or whatever you want, intentionally.

    (It’s also RESTful, since you send updates to the same URL itself, but only for the API itself. It’s intentionally self-contained at the moment, but that might change in the future.)

    Reply
  14. Bryan Petty

    @Pete – How do you feel about removing the permalink options from WordPress then? Personally, I’ve never seen a REST API who’s endpoints change depending on a customizable frontend appearance option that has nothing to do with the API.

    Permalinks are the reason WordPress can’t do that for it’s REST API, and those obviously aren’t going to disappear anytime soon, so the REST API has no choice other than to expose it’s own new endpoints.

    Reply
    1. Pete Shaw

      Bryan,

      This is not a major problem, most sites don’t change their permalink structure (mainly for seo reasons). The benefits in terms of usability, semantics, documentation etc are huge if a truly restful approach was used.

      This API is good but its needs to be truly restful.

      Reply

Leave a Reply