REST stands for Representational State Transfer. Defined and described by Roy Fielding in his doctoral dissertation while at the University of California, Irvine, REST is the underlying architectural style of the web as we know it today. RESTful systems, specifically APIs (Application Programming Interfaces) in the context of this post, are those that follow four (or five) basic principals:
- Make use of HTTP verbs
- PUT, GET (hence the capitalization of the ‘GET’ in the post title – hilarious, I know), DELETE, POST, UPDATE
- Provide a uniform structure/interface
- Properly formatted responses – JSON/XML
- Responses are cacheable
At LexBlog, we make use of a variety of different RESTful APIs – Cloudflare, Twitter, Typekit, and MailChimp to name a few. These APIs allow us to tap into deeper levels of functionality that are only exposed through APIs – an end user that was not aware or capable of using these systems would have a difficult (or likely impossible) time replicating this functionality.
APIs of this variety are one of the growing currencies of the web. The more developers and services utilize your API, the more your service becomes indispensable (whatever that’s worth – ask Twitter).
In 2013, WordPress began what would be (and still is) a long journey into the world of its own REST API. For most of its history, WordPress has relied on Dave Winer‘s XML-RPC protocol to power the externally facing API. The WordPress mobile app, for example, relies on the XML-RPC protocol. Unfortunately, XML can be difficult (or, again, likely impossible) and cumbersome to parse.
To find out more about the WordPress REST API, the video below serves as a wonderful introduction:
All of these articles/videos/tutorials are great resources as well if you want to get up and running or just learn more about the general shape of the API:
- Introduction to the REST API – on Post Status
- Rachel Baker: Build a Theme with the REST API
- The REST API (and How It Could Change WordPress Forever)
- and of course, the docs themselves along with the Github repo
As usual, the best way that I’ve found to get up and running with a piece of technology is to start using it – there are a host of tutorials, and Torque – a WP Engine site – has some of the best pieces in the developers section. There’s also a small series that is slowly filling out over on Envato’s tuts+.
That said, don’t run too quickly. The underlying infrastructure for the API is in core, but the endpoints have yet to be surfaced as some debate over how to best introduce the API has slowed down core integration. While this has spawned a series of pieces decrying the state of WordPress or made the conspiracy nuts come out of the woodwork (joking, just joking), it seems that any delay will only postpone the inevitable. The API will land in core. Period. For those of us that work in production and have thousands of client sites to maintain, it just becomes a question of how long do we have to wait before we can trust what has generally been a shifting target.