JSON REST API: Version 0.5

This week, I finally have a new release for you! Version 0.5 is now available, with the following changes (and more!):

  • Add support for media – This has been a long time coming, and it’s finally at a point where I’m happy to push it out. Good luck. (#272)
  • Separate the post-related endpoints – Post-related endpoints are now located in the WP_JSON_Posts class. When implementing custom post type support, it’s recommended to subclass this.

    The various types are now also only registered via hooks, rather than directly in the server class, which should make it easier to override them as well (#348)

  • Add page support – This is a good base if you’re looking to create your own custom post type support (#271)
  • Switch from fields to context – Rather than passing in a list of fields that you want, you can now pass in a context (usually view or edit) (#328).
  • Always send headers via the server handler – Endpoints are now completely separate from the request, so the server class can now be used for non-HTTP/JSON handlers if needed (#293)
  • Use better error codes for disabled features (#338)
  • Send X-WP-Total and X-WP-TotalPages headers for information on post/pagination counts (#266)

As always, the full changes are available if you’re interested.

This week finally brings media into the fold. The process for uploading media is a little different to creating normal posts, so here’s how you do it.

First, upload the file via a POST request to /media. This can either be as a standard HTTP multipart body, with the name field set to file, or as a raw file in the body with the Content-Type header. (You can also optionally send a Content-MD5 header if you’d like the server to check the consistency of your file.) This will give you a 201 Created status, and point you to the new resource. You can now update that resource with the correct post data.

This multistep procedure is required to enable raw file uploads, and I’m not entirely pleased with it, but it’s the only way without requiring multipart requests. I’d love to have feedback on this system, as I think practical use will eventually reveal the correct method here.

So, it’s time to start winding up the Summer of Code portion of the project. There’s still one week left for the Summer of Code project, so you may still see a release next week, but most likely in the form of smaller updates, especially with documentation and testing. As I finish up, it’s time to look forward to the future of the project. The plan is to form a Feature as a Plugin team as we work towards core integration in future releases. People have already volunteered for the team back in the 3.8 scoping days, and I’ll be getting in contact with them shortly, but it’s not too late to nominate yourself for the team; let me know if you’re interested.

Thanks to everyone for testing and for your feedback. Stay beautiful.