A Case for the WP REST API

A Case for the WP REST API

Most developers have used an API (and more specifically the REST API) in some point in their careers; and a WordPress developer is no exception. We may have used the WordPress REST API for fetching data from a remote WordPress instance, or update some record somewhere with authentication or to create a Headless WordPress site. Perhaps we simply used it within a Gutenberg block.

wp rest api

GraphQL is an alternative to the REST API, and also a great technology. However, using GraphQL with WordPress requires the installation of a new plugin. If you are using GraphQL to merely solve the under-fetching/over-fetching problem for basic queries, you might want to continue reading this post.


The easiest way to play with the WP REST API is to visit any WordPress site’s URL followed by /wp-json. I’d recommend a REST client like Postman or Insomnia. In case you do not download these apps, you can visit the URL on your browser. If you go this route, however, I’d recommend an extension to view JSON data. You can find them on your Browser’s extensions library. Taking this site as example, let’s say you visit the following URL:


You will get a huge chunk of JSON data. There will be multiple namespaces. I’d recommend you go explore the the WP namespace first:


You will get the endpoints inside of the core WP namespace. Let’s look at the latests posts:


Solve over-fetching using _fields

If you followed the last link, you would have seen a bunch of fields for the latest 10 posts. Let’s say you only need the title, and excerpt. Here comes the key part: you use the _fields URL parameter to limit the fields to just what you want:


The above will only return the posts’ titles and excerpts. This would reduce the load time significantly since it’s much less data as compared to retrieving the entire dataset from the posts endpoint.

Get the full categories, tags, and featured image

Another “limitation” with the REST API is that you cannot see the name or slug of the attached category or tag for a post if you go to the /posts endpoint.

The solution to this is to pass the _embed param to the URL.


The above will give you the terms (categories, tags) used for the posts. Additionally, you will also get the featured image details for the give post. This will save you from making multiple calls to the remote endpoint, thus saving time and money.

Although this is not a full-on nested call like you can do with GraphQL, this is good enough for a lot of use cases.

A note on using _fields and _embed

As you try to use these tips, you would be tempted to use both the _fields and _embeds params in one call. You will notice that it is not possible to do so.

When I tried the above scenario, it returned empty results. So, I followed this solution StackOverflow to get over this roadblock.


Perhaps you are discouraged from using the WP REST API because it fetches fields you do not need. Perhaps it is because the results do not contain the featured image URL or the category/tag name and slug. If so, then you might want to consider sticking to the REST API before looking elsewhere.

Leave a Reply

Your email address will not be published. Required fields are marked *