Word Rest and Play

@codekipple

 

Carl Hughes

Not to be confused with...

  • wordpress.com api (available via jetpack)
    • Not open
    • Relies on wordpress.com server
    • Has provided guidence wp-api during development
  • Unification of the two API's is planned

Beginnings

  • Started as a Google Summer of Code project in December 2012 by Ryan McCue

Lead developers

Project goals

  • The core API
    • API infrastructure
    • Core endpoints - Exposing everything in WordPress Core
  • Reference clients (php, JS, CLI)
  • Authentication schemes (Including oAuth)
  • To make minimal breaking changes (only for security issues)
  • To last for 10 years

 

https://gist.github.com/rmccue/722769379f4fc4148b1f

Current (old) API's

XML-RPC 

  • Most powerful API WordPress currently has
  • Gives access to everything in admin
  • Used by mobile apps

admin-ajax.php

  • Very lightweight routing layer 
  • Anything you build on top is custom
  • More of a tool then an API
  • used by post autosave
    and heatbeat api

API infrastructure

  • Added to core WordPress 4.4 (October 2015)
  • Foundational layer of the API
  • No endpoints

API infrastructure - Who might use it

  • Plugin authors who that want their own REST API

 

  • Woocommerce
    (currently using an early forked version of WP REST API)

Core endpoints

  • Currently a feature plugin
  • Coming to WordPress core soon

https://make.wordpress.org/core/features-as-plugins/

Core endpoints - fields

  • Consciously renames some WordPress fields for consistency 
    • Removing eccentricities of WordPress naming

Posts

Core endpoints - fields

Comments

Core endpoints - fields

Terms

Core endpoints - fields

Users

Authentication

  • oAuth 1.0a
    • Not using oAuth 2 because it requires HTTPS
      • most WordPress sites don't have SSL
    • Requires the installation of oAuth wp plugin
    • Is intended for inclusion in core

Eveloping

  • To trigger enveloping, we can append a _envelope parameter to the request URL (i.e. /users/me?_envelope)
  • Inspired by technique used on the wordpress.com API
  • Always uses 200 status
  • Can't trust servers, proxies, HTTP clients
  • Some environments block or divert responses with a non 200 HTTP status
  • Sneak past proxies
HTTP/1.1 200 OK

{
    "status": 200,
    "headers": {
        "Location": "http://example.com/wp-json/wp/v2/users/42",
    },
    "body": {
        "id": 42,
        ...
    }
}

Javascript client

  • Uses backbone and underscore included with WordPress
  • Backbone Models and Collections for all endpoints exposed by the API Schema.
  • Is intended for inclusion in core 
  • Specifically designed for themes and plugins
  • Just an optional addition on top of the API

client-cli

 

Daniel Bachhuber (@danielbachhuber) successfully

funded a kickstarter to overhaul WP-CLI to use the

WP REST API.

  • All WP REST API endpoints registered
    via plugins and themes will

    automagically be usable as
    WP-CLI commands.

How could this change things?

Alternative admin UI's

  • UI's like wordpress.com calypso
    https://developer.wordpress.com/calypso/
  • Admins build for singular use cases
    (a specialsed media manager)

New developers

  • Themes built using front-end frameworks like React and ember 
  • New developers jumping into the WP ecosystem that don't normally like working WordPress or PHP

Apps/Multisite

  • Native apps that easily share the same data as your WP website
  • Multisite without using WP multisite
  • Seperation of front-end from the WP powered back-end

Interesting plugins

  • leveraging the WP REST API endpoints
  • Creating their own endpoints
  • Replacing core endpoints?

Hard to tell where this will lead

  • Lots of experimenting and fun
  • Developer education of the benifits of REST API's
     
  • Death of WordPress?

Further reading

Thanks

Text

Any questions?

Made with Slides.com