The WordPress REST API is in the process of changing WordPress. You may not have noticed, as a lot of it is under the hood, but the implications of the REST API make a huge difference to the future of WordPress, both in terms of its codebase and its uses.
If you haven’t worked with the WordPress REST API, you might be wondering just what it is. So let’s kick off by looking at what the REST API is.
What is the WordPress REST API?
REST stands for Representational State Transfer and API stands for Application Programming Interface. Let’s take a look at what each of those means.
What is an Application Programming Interface (API)?
An Application Programming Interface, or API, is defined as:
“An interface or communication protocol between a client and a server intended to simplify the building of client-side software.”
If you aren’t familiar with APIs, that may not help very much. To put it more simply, an API is a set of code that allows one system to interact (or “interface”) with another. If you’ve ever added a Google map to your WordPress site, you’ve used Google’s Maps API, which allows your WordPress site to interface with Google Maps.
These systems don’t need to be completely separate. WordPress already has multiple APIs, for things like plugins, settings, and shortcodes. These can be used by plugin and theme developers to interact with WordPress core and make things happen (like creating shortcodes and adding settings screens to the WordPress admin).
The difference with the REST API is that it allows systems outside your WordPress installation itself to interact with WordPress, which is where the REST part comes in.
What is Representational State Transfer (REST)?
Representational State Transfer, or REST, provides standards that web systems can use to interface with each other. Without REST, two systems wouldn’t be able to understand each other and so send data back and forth.
For an application to be RESTful, it must conform to five principles:
- Uniform interface. The URLs used to access resources in the system have to be uniform, consistent, and accessible via a common approach such as GET (more of which shortly).
- Client-server. Client applications and server applications must be separate, so they can be developed independently of each other. If the server-side technology (i.e. WordPress) changes, the server-side application (an app, for example) must still be able to access it via the same simple method.
- Stateless. The server doesn’t change state when a new request is made using the API. It doesn’t store the requests that have been made.
- Cacheable. All resources must be cacheable, to improve speed and conformance
This article was written by Rachel McCollin and originally published on Blog – Kinsta Managed WordPress Hosting.