 Okay. Hello. This is lots of people. Yeah. The WordPress REST API. So now I have everybody here from my very clickbaity title. I'm going to exploit that. So typically, when, you know, you write a talk, then you try and keep things simple and have a few themes that you reiterate and do that, and that is completely the opposite of what I have done for this talk. So it is a bit of a train moving through, and hopefully it will somehow end at the right point at the end of this hour session. Should always say, like, we're going to have, like, a couple of minutes intermission in the middle if anybody wants to leave or come in from our sessions. So there's, yeah, a good amount to get through here. So let's go. And it's probably worth bearing in mind if they like code concepts and things that I have. It's quite pseudo-code, so it's not all copy-pasteable. It's more about the ideas and things like that. So obligatory first slide. What is an API? We probably all know what an API is. Here's me using REST API console to make some requests to the WordPress REST API to show you how that works. So we can request some posts. We can add some parameters to change the data that is returned from those endpoints. That's pretty much how it works. I don't think we need to kind of go into a lot of detail there. The more important question is probably why a REST API, especially when we're talking about trying to get this immersion to core, this is quite an important question. So having a REST API just allows us to open up WordPress in a programmable way to every other platform, language system out there, so we can just make WordPress as part of lots of other things rather than being a little siloed thing. That's pretty much how I think about it. Anyway, the REST API doesn't really do anything on its own. It's just a mechanism of which to interact and kind of bootstrap that. So here's a quick demo of me making an HTTP request on the command line to list some posts. So you can see I get my posts. And then I can also search for something, get a little post with world, and I can pipe that into JQ and list the titles of those posts, and I can also get those posts URLs in the API, and then I can use that in turn to send delete request to those posts to delete everything with the word world in it, and then just go to the admin to verify that it's done. So that's quite a simple program that I made there just on the command line, but you can see that you can open up WordPress to this world of possibility where you can use it for a lot of different things. So the kind of format that I want to go is a journey through the REST API in time to kind of outlay the kind of different decisions and features that have been built along the way, and hopefully within that you'll be able to get all of the concepts, et cetera. So it started how long ago is this? Three and a half years ago, so yeah, it's been a pretty long project founded by Ryan McQ as a gist over Christmas, because I guess that's what Ryan does at Christmas. So January 2nd, this 590 line patch lands on GitHub, and forward another six months, because that's how Ryan works, I decided to make it a Google Summer of Code project, so that will enable him to work over the summer on this idea that he has for core to have a WordPress REST API sponsored by the Google Summer of Code project. So primarily, Ryan and Rachel Baker work together on building out what is kind of dubbed version one of the REST API, and that is released version one stable one whole year later. So that's a lot of work that kind of went into that version one, and was used to a pretty large degree as well. It allowed access to the core WordPress data types. It was read and write, and broadly speaking, it's a very good API, but having several problems in terms of its goal of getting into WordPress core, but was utilized a lot for plugins and things like that for custom development. So to try and address some of those shortcomings, though it was a solid API, I think it was just missing some key things that were going to be required for WordPress inclusion. It had no real internal API for registering routes and things like that, so I guess something akin to register post type or something. Before that, you could still register post types in WordPress. You just had to filter things, et cetera. That's kind of how version one of the API worked. It was also a little tricky to extend. Most of the endpoints had just been written for purpose for doing the thing that they had done, rather than being reusable blocks of code, so it was a little more tightly coupled and more difficult to do because of that. So we decided, I guess, this is when I got involved with the project along with Daniel Bachuba, to do version two of the REST API to kind of have a run over again, I suppose, see if we could get something that was more appropriate for core inclusion, was the primary kind of focus on that. So this is where I decided to get involved, and probably the date that I remember the best for the biggest regret of the last several years. The first thing that we focused on in version two or one of the first things was the idea of that being a metadata level on top of the API, often referred to as schemas, which is a programmatic way to read the API and interact with it in a more automated fashion, rather than needing to be completely custom implementations for this specific WordPress REST API. So you're probably wondering what the heck that means. It's a little abstract, so I kind of give a quick demo here. I make a GET request to a post, and when I do that in the API, I get a response for the post object. The post object has a little more data than this, but you kind of get the idea. If I send an options request to the same URL with the REST API, I get this big JSON schema blob telling me what all of these different fields mean, so I can use this for things like documentation and things like that. And as you can see, there's like a one-to-one pairing typically between the properties and then a programmatically readable description and definition of what that field is. Like I said, this can be used for documentation, which is kind of handy. You can also use it to build an automatic UI in clients, so maybe if it's a custom post type that isn't a recognized data format, you could have a client that is automatically rendering different fields based off of the automatic description of those. So, for example,