A bunch of teams within Automattic have spent the last week or two reviewing the REST API from the perspective of how it compares to their usage of the WP.com REST API. Here’s a summary of their thoughts – I’ve stripped it down to the bare minimum, I can drag people in if you’d like more info. 🙂
Posts and Pages
We use an endpoint to retrieve post-counts for different post-type-statuses (e.g., draft posts, or published pages), so that we can limit the status-selector to those that are relevant and to show the counts in the UX.
The request for post-counts is implemented as its own endpoint, but can also be combined with the post-list endpoint, so we can retrieve the data we need for that page in a single query.
In the wpcom rest-api, in the Post object, we deliver an object showing the current user’s available permissions, which we use to determine which controls to show the user on the front end. I see some permission checks happening in the Post object request for wp-api, but I don’t see permissions being returned as part of the response.
There doesn’t seem to be a method for getting theme supported formats for a site.
In addition to page/offset parameters, the WP.com API has a page_handle parameter for faster paging through post lists.
Nothing in settings has been implemented.
Nothing in themes has been implemented.
In particular, there’s no way to retrieve or set add_theme_support() type things. Featured image, registered nav menus, content_width, etc.
Missing pagination, total count and search.
There’s nothing implemented in the core REST API, but there is a “WP-API Menus” extension, which has a bunch of problems compared to WP.com:
- Read only.
- Uses a flat data structure rather than a tree data structure. Clients could change to cope with this difference, but it’d be easier to have things the same from the start.
Missing site, theme and plugin updates [display and actions].
We’ve run into many performance problems, particularly with endpoints that need to parse post content. Are there any performance tests available, with very large data sets? How does it compare to XML-RPC?
The /batch endpoint encourages apps written for the WP.com to be efficient with round trips. For example, a first request could get a list of posts, then a second request could make requests to different endpoints for each of those posts, all at once.