I’m incredibly excited to announce the availability of version 1.0 of the JSON REST API.
This version is a huge release and introduces a bunch of new features, such as user, revision and post meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. endpoints. It also introduces our long-term backwards compatibility policy, aligning with WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. backwards compatibility.
Here’s a selection of the new stuff:
Add user endpoints.
Creating, reading, updating and deleting users and their data is now possible
by using the
/users/me can be used to determine the
current user, and returns a 401 status for non-logged in users.
Note that the format of post authors has changed, as it is now an embedded
User entity. This should not break backwards compatibility.
Custom post types gain this ability automatically.
(props @tobych, @rmccue, #20, #146)
Add post meta endpoints.
Creating, reading, updating and deleting post meta is now possible by using
/posts/<id>/meta endpoints. Post meta is now correctly embedded into
Meta can be updated via the Post entity (e.g.
/posts/<id>) or via
the entity itself at
/posts/<id>/meta/<mid>. Meta deletion must be done via
DELETE request to the latter.
Only non-protected and non-serialized meta can be accessed or manipulated via
the API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. This is not predicted to change in the future; clients wishing to
access this data should consider alternative approaches.
Custom post types do not currently gain this ability automatically.
(props @attitude, @alisspers, @rachelbaker, @rmccue, @tlovett1, @tobych,
@zedejose, #68, #168, #189, #207)
Add endpoint for deleting a single comment.
Clients can now send a
DELETE request to comment routes to delete
Custom post types supporting comments will gain this ability automatically.
(props @tlovett1, @rmccue, #178, #191)
Add endpoint for post revisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision..
Post revisions are now available at
/posts/<id>/revisions, and are linked in
meta.links.version-history key of post entities.
Custom post types supporting revisions will gain this ability automatically.
(props @tlovett1, #193)
Respond to requests without depending on pretty permalink settings.
For sites without pretty permalinks enabled, the API is now available from
?json_route=/. Clients should check for this via the autodiscovery methods
(Link header The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. or RSD).
(props @rmccue, #69, #138)
Add register post type argument.
Post types can now indicate their availability via the API using the
show_in_json argument passed to
register_post_type. This value defaults to
publicly_queryable argument (which itself defaults to the
(props @iandunn, @rmccue, #145)
Remove basic authentication handler.
This breaks backwards compatibility for clients using Basic
authentication. Clients are encouraged to switch to using OAuth
authentication. The Basic Authentication plugin can be
installed for backwards compatibility and local development, however should
not be used in production.
(props @rmccue, #37, #152)
Require nonces for cookie-based authentication.
This breaks backwards compatibility and requires any clients using cookie
API automatically handles this.
(props @rmccue, #177, #180)
Clean up deprecated methods/functions.
Functions and methods previously deprecated in 0.8/0.9 have now been removed.
Future deprecations will take place in the same manner as WordPress core.
This breaks backwards compatibility, however these were marked as
deprecated in previous releases.
(props @rmccue, #187)
Only expose meta on ‘edit’ context as a temporary workaround.
Privacy concerns around exposing meta to all users necessitate this change.
This breaks backwards compatibility as post meta data is no longer
available to all users. Clients wishing to access this data should
authenticate and use the
(props @iandunn, @rmccue, #135)
json_ensure_response function to ensure either a
WP_JSON_ResponseInterface or a
WP_Error object is returned.
When extending the API, the
json_ensure_response function can be used to
ensure that any raw data returned is wrapped with a
This allows using
get_data easily, however
still be checked via
(props @rmccue, #151, #154)
Use version option to check on init if rewrite rules should be flushed.
Rewrite rules on multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site are now flushed via an init hook, rather than
switching to each site on activation.
(props @rachelbaker, #149)
As always, you can view all commits or the longer changelog.
For those interested, here’s the list of contributors to this release:
$ git shortlog --summary 0.9...
1 Chris Marslender
1 Eric Lanehart
2 K.Adam White
1 Kat Hagan
41 Rachel Baker
139 Ryan McCue
5 Taylor Lovett
10 Toby Champion
There’s a few really important things to note with this release.
Authentication has changed significantly in 1.0. If you’ve been using Basic authentication previously, you’ll now need to install the Basic authentication plugin. This plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is designed for local development, as Basic authentication requires sending your plaintext credentials over the wire, which is unsafe for production.
Production users have two choices: built-in cookie authentication, or OAuth authentication. OAuth 1.0a is an authorization protocol that allows you to authorize clients to act on your behalf, and does not require giving your username and password to the client. It does, however, require a significantly more complicated authentication/authorization process, and clients are required to register on the site beforehand. We’re working on long-term solutions to this.
From this release forwards, backwards compatibility will not be broken. This includes both the internal PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher API, as well as the REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. we expose. New endpoints may be added, as well as new data, but responses will continue to be supersets of the current response.
The exception to this is for security concerns. As we continue development, we may need to change some endpoints for security issues, as we did with post meta for this cycle. These will be announced well before release where possible.
Please note also that this release has removed some previously deprecated methods and changed some internal implementation details. This only affects plugins or themes that extend the API.
We’re pushing hard for integration into 4.0 this cycle, and we need your help. Our core integration plan outlines the motivation behind the project and the specific plan for integrating it into core. We’re currently working on a comparison document for the API compared to the WP.com/Jetpack API and others, and will be publishing that soon.
We need your help to make it into 4.0. Developers, we’d love to know what you’ve built with the API, whether public or internal (even vague details help!), and we’d especially love to see things built with the API. We’re currently in danger of not making it in this cycle, so anything you can do to help us here would be fantastic.
You’re always welcome over at the team o2, and our next meeting will be at Tuesday, 00:00 UTC; we’d love to see you there. If not, see you soon for version 1.1!