This is going to get a bit more technical today, but I think that the technology called REST API is something that most of you kind of intuitively know, but maybe you don’t know what to do with it. So let me show you what I’ve understood and used so far.
Table of Contents
The word REST stands for Representational State Transfer and the word API stands for Application Programming Interface. So API is a tool for communication between applications and REST is a certain standard containing tools, rules and definitions of how that communication should take place. A clear explanation of the issues can be found e.g. on the web site https://restfulapi.net and of course also briefly in the Wikipedia article on REST. The REST API is one of the options for communication between applications, another is SOAP or the older XML-RPC, which also still remains in WordPress.
WordPress has had a REST API integrated into the core since version 4.7 released in December 2016, before that the feature was developed as a plugin. There is clear and sufficient documentation for this on the developer portal.
Caution, do not confuse REST API with webhooks! For example WooCommerce has had them for a very long time, it’s the address of a script that accepts arguments in the url and processes them in some way. The principle is similar, but a webhook is a purely individual thing that has no standard.
How the REST API (in WordPress) works
The API is defined using access points, which are special addresses. They start at the /wp-json/ slug because the REST API in WordPress returns data in JSON format (other APIs use XML). At a given end-point, you’ll find a structured document and in it you’ll find the site name, address, favicon, and most importantly a list of all the namespaces. This is a submenu of functions that can be used. You can use these to see which plugins work on the site, because many plugins „have an API“, i.e. they add their namespace (according to the functions they offer).
Namespaces
WordPress core
- wp/v2
- wp-block-editor/v1
- wp-site-health/v1
- oembed/1.0
Selected plugins
- complianz/v1, contact-form-7/v1
- elementor-pro/v1, elementor/v1, elementskit/v1/layout-manager-api, elementskit/v1/megamenu, elementskit/v1/my-template, elementskit/v1/widget-builder, elementskit/v1/widget/mailchimp
- jetpack/v4, kb-activecampaign/v1, kb-mailerlite/v1
- mc4wp/v1, rankmath/v1, yoast/v1, redirection/v1, wordfence/v1
WooCommerce
- wc-admin, wc-analytics
- wc-facebook/v1, wc-telemetry, wc/store, wc/store/v1, wc/v1, wc/v2, wc/v3
Routes and methods
The path to the methods that are defined in each namespace is through a route, a structure expressed by a URL. You need to know where to send the request to get the data back. It’s actually a help file with a list of all possible requests (methods) and their arguments (these are listed deeper in the structure).
The request can be any of the types summarized by the acronym CRUD:
create(POST or PUT method)read(GET method)update(POST method)delete(POST method)
This allows you to work with the data inside the site – get a statement, edit the data, create new data or delete it. As you can see from the situation, you don’t need any WordPress graphical application for this, just its core that can handle these queries. And we are already at the possibilities
- integration with other applications
- creating your own mobile app
- launching a headless website (administration is separated from the frontend)
That’s a good thing, isn’t it?
You can see the arguments of the query in the following figure. You can also see that this is a GET method (i.e., retrieving data using the arguments in the url).
Listing of the last 10 articles:
https://wp-admin.cz/wp-json/wp/v2/posts
Listing of the last five articles:
https://wp-admin.cz/wp-json/wp/v2/posts?per_page=5
The listing of five articles in the status for a future release already returns an authorization error:
https://wp-admin.cz/wp-json/wp/v2/posts?per_page=5&status=future
It’s understandable, it’s already intimate information of the site, we don’t want that. It follows that access to the data replicates the rights settings of the entire system.
Data can also be inserted into the system, the POST method is used for this. But you can’t simulate it in the browser anymore, you need software that can do it and is easy to use. I’ve grown fond of the Postcode add-on to VS Code, where I often work. In order to post requests, you need a credential, or authorized access. Fortunately, application passwords have existed for quite a long time, i.e. access for an application user who cannot log into WordPress but is authorized to handle data according to the rights that each namespace (=plugins) has.
Authorization
Create a user for automated access (so some funny robotic name), set a difficult password, but you won’t need it. Now in his profile, enter a name for the application password and it will be generated in the next step. If WordPress writes it there, you won’t see it again, so make a note of it, or just generate it again.
And now the Postcode or other query tool (there are more). To execute a query you need to have a route (i.e. destination url) including its arguments, a login name and an application password (not a login password if you have an application one!). Don’t use regular user access, it’s a security risk, create an application password.
Then enter the individual keys and values according to the „help“, i.e. the listing obtained by the GET method in the given namespace, see above. During testing I encountered a problem with the length of the request, e.g. the content of the post could not be inserted, but this is a matter of setting the headers correctly.
The result is what we expect. The article titled „Greetings from a robot“ is published under the name of the corresponding user and is assigned to the section with id 3. It has no content.
Why use the REST API?
Now, dear fantasy, run! What can a good administrator do about it? What information do SEO plugins offer, what can I learn about orders in WooCommerce? What can I remotely find out from Site Health? Or activity logs.. it’s all used by management apps like MainWP, which you’ll read about soon. Or no-code platforms like Make, Zapier. The REST API is used by Gutenberg and WooCommerce and many other plugins.
You can export your data even if you don’t have a suitable plugin. You can connect it to another application for business logic or e-shop economics processing. Not everything is quite ready, but that’s what you should check!
What to watch out for
From a security standpoint, it’s practical to disable queries to users so that robots don’t have such an easy time finding them. You won’t find information about WordPress versions or components in the REST API. However, content is available according to defined access rights – all articles displayed on the site are also available through the REST API. But the RSS feed of the site and each section offers the same.
I would check for custom plugins to see if they have well handled access to member sections, or to form data or logs. It’s nothing special, logs can be found in any directory and we should keep an eye on their availability.