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
- Ryan McCue @rmccue
- Rachel Baker @rachelbaker
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
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
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
- Not using oAuth 2 because it requires HTTPS
-
HTTP Basic Authentication
- Useful during development, not intended for production use.
- requires installing either the Basic Auth plugin or Application Passwords plugin
- Is not 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
- Integrate with WP-CLI
https://github.com/WP-API/client-cli - Not intended for inclusion in core
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?
