Custom post types and taxonomies are registered in the REST API response on a case-by-case basis using three dedicated arguments in the registration. That way you can choose which custom post types and taxonomies are available from the REST API and what their routes are.
- [Man] Custom post types and taxonomies are pretty much expected editions anytime you build an advanced WordPress site or service. And, now that we have the REST API, we need to make sure we're able to add these custom post types and taxonomies into the REST API response, if we need them to be there. REST API support for custom post types and taxonomies is enabled in the original registration of these items, and the WordPress developer handbook provides all the information we need, both on this page, Adding REST API Support For Custom Content Types, and in the documentation pages for register_post_type and register_taxonomy. For both of these functions, there are three relevant arguments we need to be aware of. The first one, show_in_rest, is a bullion argument that toggles REST API support on and off. If it's set to "true", then the item becomes available in the REST API. If it's set to false, it's not available in the REST API. The next one, rest_base, allows you to change the name of the route. So, the sample provided here in the documentation is if you register a pulse type called "book", so singular, and you want the route to be "books" plural, you would use rest_base to set that plural name. That also means you can set the rest_base to anything you want. So instead of having wp/v2/books, you could have wp/v2/boker if you want to do it in Norwegian, or something else. It's entirely up to you. Finally, you have this one, REST controller class which allows you to apply a different controller class to this particular content type. Now, in most cases, when you set up a custom post type or taxonomy, the only thing you need to toggle is show_in_rest, make sure it's set to true, and then everything passes through. The two other arguments are more advanced, and are more rarely used, but, if you want to use them, all the documentation is there for you. Registering custom post types and taxonomies can be done in two main ways, either you write all the code yourself and put it into a functionality plugin or something else, or you use a plugin to register them on the site, and that's what I've done. It's because the procedure here is exactly the same, whether you use code or plugin to do it. I've used the Custom Post Types UI plugin to create a new custom post type called classes, you can see it here, there are two posts, and the classes post type has two custom taxonomies, teachers and years. Now, by default, this plugin registers everything with the REST API, so I manually went in and turned it off, because I want to show you what happens when you turn custom post types and custom taxonomies on in the REST API. In Postman, I'll go to the local site, and I want to go to Post Types over here. This should give me a list of all the available post types on my site right now, and, I'll remind you, I have not registered this new custom post type yet. So, If I scroll down, you'll see the list is currently post, so post, page, pages, attachment, which are the attachment pages, that's the pages that are created any time you upload an image, or media item of some kind. Then, you have wp_block, which is related to the block editor, and that's it. So, we have these four different post types. Now, if I go into the CPT UI admin, and go to Post Types, or if I go into my code, and find the post type in question, then go in and find the value called, let's see, show_in_rest, and set that to true, and save the file. I can go back into the REST API, and just make the same request again. Now, when I scroll to the bottom of the response, you'll see I have a new item, classes, and this is the new custom post type, so that's really all there is to it. I register it for the REST API, it shows up in the response. Now, I can do the same with taxonomies, so I'll do a taxonomy query here to see what taxonomies are available, right now, I should have two types, that would be category and tags. If I go into Custom Post Types UI and go to edit taxonomies, and then find teachers first, scroll down, let's see, where are you? Under settings, we find show_in_rest... there we go, show_in_rest, true, save taxonomy, then go up and change to years, scroll all the way down, show_in_rest, and true again, save taxonomy. I can then jump back to Postman, resend the taxonomy query, and I now have four responses: category, tag, teachers, and years. So, your takeaway here is this: anytime you register a new custom post type or taxonomy, and you want it to appear in the REST API, go set the show_in_rest attribute to true. If you want to modify it further, either by changing the REST base, or by changing the controller class, you can do so as well by setting the REST base argument, or the REST controller class argument.
Morten begins by providing an in-depth look at how the REST API works, discussing how it allows clients to access the data in a WordPress site without going to the WordPress site itself. He demonstrates the use of routes, endpoints, requests, responses, and more. Plus, he provides several practical examples of how the WordPress REST API can be used in the real world.