Backbone library for the WordPress REST API or "WP-API"

Summary

This library provides an interface for the WP REST API by providing Backbone Models and Collections for all endpoints in the API.

Using

Activate the WP-API plugin. Enqueue the script directly:

wp_enqueue_script( 'wp-api' );

or as a dependency for your script:

wp_enqueue_script( 'my_script', 'path/to/my/script', array( 'wp-api' ) );

The library parses the root endpoint (the 'Schema') and creates matching Backbone models and collections. You will now have two root objects available to you: wp.api.models and wp.api.collections.

The models and collections include:

Models:
 * Category
 * Comment
 * Media
 * Page
 * PageMeta
 * PageRevision
 * Post
 * PostMeta
 * PostRevision
 * Schema
 * Status
 * Tag
 * Taxonomy
 * Type
 * User

Collections:
 * Categories
 * Comments
 * Media
 * PageMeta
 * PageRevisions
 * Pages
 * Posts
 * Statuses
 * Tags
 * Taxonomies
 * Types
 * Users

You can use these endpoints as-is to read, update, create and delete items using standard Backbone methods (fetch, sync, save & destroy for models, sync for collections). You can also extend these objects to make them your own, and build your views on top of them.

Default values

Each model and collection includes a reference to its default values, for example:

wp.api.models.Post.prototype.args
 * author: null
 * comment_status: null
 * content: null
 * date: null
 * date_gmt: null
 * excerpt: null
 * featured_image: null
 * format: null
 * modified: null
 * modified_gmt: null
 * password: null
 * ping_status: null
 * slug: null
 * status: null
 * sticky: null
 * title: null

Available methods

Each model and collection contains a list of methods the corresponding endpoint supports. For example, models created from wp.api.models.Post have a methods array of:

["GET", "POST", "PUT", "PATCH", "DELETE"]

Accepted options

Each model and collection contains a list of options the corrosponding endpoint accepts (note that options are passed as the second parameter when creating models or collections), for example:

wp.api.collections.Posts.prototype.options
 * author
 * context
 * filter
 * order
 * orderby
 * page
 * per_page
 * search
 * status

Localizing the API Schema

The client will accept and use a localized schema as part of the wpApiSettings object. The Schema is currently not passed by default; instead the client makes an ajax request to the API to load the Schema, then caches it in the browser's session storage (if available). Activating the client-js plugin with SCRIPT_DEBUG enabled uses a localized Schema. Check the client-js example or this branch which attempts to only localize the schema once per client.

Waiting for the client to load

Client startup is asynchronous. If the api schema is localized, the client can start immediately; if not the client makes an ajax request to load the schema. The client exposes a load promise for provide a reliable wait to wait for client to be ready:

wp.api.loadPromise.done( function() {
	//... use the client here
} )

Model examples:

To create a post and edit its categories, make sure you are logged in, then:

// Create a new post
var post = new wp.api.models.Post( { title: 'This is a test post' } );
post.save();

// Load an existing post
var post = new wp.api.models.Post( { id: 1 } );
post.fetch();

// Get a collection of the post's categories (returns a promise)
// Uses _embedded data if available, in which case promise resolves immediately.
post.getCategories().done( function( postCategories ) {
	// ... do something with the categories.
	// The new post has an single Category: Uncategorized
	console.log( postCategories[0].name );
	// response -> "Uncategorized"
} );

// Get a posts author User model.
post.getAuthorUser().done( function( user ){
	// ... do something with user
	console.log( user.get( 'name' ) );
} );

// Get a posts featured image Media model.
post.getFeaturedImage().done( function( image ){
	// ... do something with image
	console.log( image );
} );

// Set the post categories.
post.setCategories( [ 'apples', 'oranges' ] );

// Get all the categories
var allCategories = new wp.api.collections.Categories()
allCategories.fetch();

var appleCategory = allCategories.findWhere( { slug: 'apples' } );

// Add the category to the postCategories collection we previously fetched.
appleCategory.set( 'parent_post', post.get( 'id' ) );

// Use the POST method so Backbone will not PUT it even though it has an id.
postCategories.create( appleCategory.toJSON(), { type: 'POST' } );

// Remove the Uncategorized category
postCategories.at( 0 ).destroy();

// Check the results - re-fetch
postCategories = post.getCategories();

postCategories.at( 0 ).get( 'name' );
// response -> "apples"

Collection examples:

to get the last 10 posts:

var postsCollection = new wp.api.collections.Posts();
postsCollection.fetch();

to get the last 25 posts:

postsCollection.fetch( { data: { per_page: 25 } } );

use filter to change the order & orderby options:

postsCollection.fetch( { data: { 'filter': { 'orderby': 'title', 'order': 'ASC' } } } );

All collections support pagination automatically, and you can get the next page of results using more:

postsCollection.more();

to get page 5 of a collection:

posts.fetch( { data: { page: 5 }  } );

check if the collection has any more posts:

posts.hasMore();

Working With Revisions

You can access post or page revisions using the PostRevisions or PageRevisions collections or through the Post or Page collection.

For example, to get a collection of all revisions of post ID 1:

var revisions = new wp.api.collections.PostRevisions({}, { parent: 1 });

Revision collections can also be accessed via their parent's collection. This example makes 2 HTTP requests instead of one, but now the original post and its revisions are avaible:

var post = new wp.api.models.Post( { id: 1 } );
post.fetch();
post.getRevisions().done( function( revisions ){
console.log( revisions );
});

If you add custom endpoints to the api they will also become available as models/collections. For example, you will get new models and collections when you add REST API support to your custom post type. Note: because the schema is stored in the user's session cache to avoid re-fetching, you may need to open a new tab to get a new read of the Schema.

Development

To develop, build and test this library, you must have Node installed. For Windows users, simply download and install Node. For Mac users, we recommend installing Node using Homebrew. Once Homebrew is installed, run brew install node to install Node.js.

Installation

Clone this repository, and then execute the following commands within the checkout directory:

$ npm install

This will use Node's NPM package manager to install all the dependencies for building and testing this library. We use Bower to manage client script dependencies, but Bower script installation is handled as part of the npm install command.

Building

To update the compiled JavaScript files in the build/ directory after you've made changes, run the library's build script with the npm command:

$ npm run build

This will use Grunt to check the source scripts in js/ for syntax errors, then concatenate and minify them to create the minified wp-api.min.js file and a corresponding source map file.

Testing

You can run the unit tests for this library using Grunt:

$ npm test

A note on Grunt

The custom "build" and "test" scripts defined in this library's package.json enable access to Grunt's functionality after a simple npm install; however, these commands can also be run directly using Grunt itself. In order to gain access to the grunt console command, you must globally install the Grunt command-line interface:

$ npm install -g grunt-cli

Once grunt-cli has been installed, you can run the build and test commands with grunt and grunt test, respectively, without having to invoke the scripts via NPM.

jazbek / client-js