Extending the REST API

Adam (presenter): Thank you for joining me. I'm Adam Berneauh, I'm a developer. I use he/him/his as my pronouns and I'll talk about extending WordPress API. There are objectives for the 9.5 minutes. Introduce WordPress Rest API, methods for extending API, and why you might want to. Without further ado, let's start.

You need to know the basics of the WordPress items. representational state transfer, RST, is something WordPress supports. Data is notated in the object format. I strongly encourage you to look at these on your own, as necessary. In addition, we'll specifically be discussing development in WordPress and PHP. In reality, you may need additional experience to extend WordPress API, but this is enough for the presentation. I'll refer to functionality in 5.4.

Quick aside, one thing to note. If you're playing in your own environment and RST API isn't responding, enable pretty permalinks, the plain style isn’t compatible.

Functionality that comes out of the box with WordPress. That is to say, you can access most of the content in WordPress through the existing API in Core. There are two namespaces, WPB2, OMBed. These endpoints give you the data you need to create an iframe in another site. The namespace you are likely to deal with is API version 2, where you retrieve content, like a post. Aren't we talking about extending API, what about WordPress Core? Yes. This brings us to this fact. The wheel is invented. If the data is available for the API, don't create your own. It's unwise. If the data isn't available for the API, we'll discuss a few methods to make it available.

The simplest way is to use show and rest on existing content. We'll start there. You created custom content that isn't showing up in REST API, you can register the content. Using one attribute is the best scenario, but review the handbook for additional steps to make the endpoint complete and robust.

In this snippet, we use show and rest when registering book data and making it available. This is available in the handbook with custom post types and taxonomy. When you access the corresponding endpoint, you receive a response with the content. In this case, books in the system. The data is added to WP namespace by default.

Maybe we don't want to show custom content, but additional fields on an existing object. For instance, URL for a featured image. We use register/rest field. When you register a rest field, it can be an object, post, comment, etc., and the attribute is the name on the object you register. The final parameter can include schema and GIT and update requests.

Let's look at adding an image URL through the REST API. We register a field, featured image source on the post objects. The actual work is done in the GIT callback function to retrieve the data we need. Once you complete the steps, request post through API and they include an attribute, "featured image source" with the link to the image. Simple as that.

A word of warning. It's possible to do so, but changing or removing data from the core API can break the plugin and should be avoided. Your code should only create additional fields. If you find your requests turn too much data, use field promoter and narrow the date to the fields you're interested in.

Finally, I want to spend time talking about the powerful and flexible way, register rest route. When you register your own route, the sky is the limit, or more accurately, the development time is the main limitation.

There's substantial boilerplate code. You create your own namespace and route and methods for the different requests. I'll stop there. There's an excellent code simple in RST API that includes 254 lines of code with stub functionality and no real features. That's in the custom endpoint section.

You can do whatever you want, return results of a custom theory, enable WordPress users, get data from custom tables, provide data for JavaScript components or RST API. These are a couple of examples. I'll focus on the last. We are building a dynamic block and use JavaScript and the editor. Some of you have code that accessing the external API, like this. That's okay, me too.

Why am I calling this an antipattern? Code quality. If external API changes/breaks, you're at its mercy. It makes the code difficult to test. Own your endpoints, instead. When you control the code that brings data in the system, it gives you the opportunity to massage the data, as necessary, or use a different extern API without the code being wiser. Your JavaScript won't have to do battle with cross-origin.

A better setup looks like this. Instead of accessing an external API, use your own API for the HPH code. Your code will also be more testable. Use transients and WordPress. For very simple WordPress, transients are faster than direct interactions with an external API.

With that, let's talk about plugins that extend the RST API. To provide authentication, use application passwords to manage their access. Aside from that, popular plugins have RST API functionality. This is just a list of popular plugins that include RST API functionality.

I'll wrap up there. If you have questions in the chat, I'll do my best to answer them if I have time. Follow me on Twitter, though I'm not especially active. If you want to chat, send me an email. Thanks for joining me.