 Hi, there. So nowadays, when you go to a conference, WordPress conference of any kind, it's hard to avoid a talk about the REST API. And I'm not going to be an exception to that rule. So briefly today about how you can practically use WordPress is the REST API that already exists in the core. And specifically, how you can use that to replace the admin Ajax.php and why I think that should be avoided. So as you know, when you communicate with the JavaScript and the PHP side, you use Ajax to do that. And historically in WordPress, you do that by calling this cryptic.php.admin.ajax.php, which even though it has admin twice in the URL, doesn't have to do anything with the admin functionality at all. And I think that it's bad. Well, I don't think it's bad, but it has a lot of limitations. One of the biggest reason is that it's very inefficient. And the reason that is is that it's run on the admin context. And a lot of, especially bad plugins, load a lot of stuff, assuming that it is needed in the WordPress admin, but it might not be. So that can really bring the server down, especially because those calls cannot really be cached because they've used historically in many different ways. And some specific hosts even advocate using admin Ajax as a way to bypass the cache. So if you're in a shared hosting environment or something like that, it can really bring the server down if you have bad plugins installed. Also, it doesn't have any sort of infrastructure in terms of authentication or data validation or anything like that. So it's very basic. And that can lead into messy code, my favorite thing. So it's too ad hoc for a lot of things. But in 4.4 version of the WordPress which came out last December, we now have the REST API kinder. I say kinder because there are no built-in endpoints yet just the infrastructure part, which means that there are the auto layers of that API are still missing. So you can't really work with the native data types yet. Except if you install the 4.4 REST API plugin, but that's still under development and the API is not frozen yet fully. So you need to be able to track those changes and modify your code accordingly. The freeze is coming, though. But anyway, if you have the installed, then you can do a lot without writing any PHP code. You can, for example, query related posts by category, for example. Or you could build a form for your users to post stories provided that the permissions are set correctly. But what can you do without what the core already has? Well, I'll give you an example. And my example is this comment reactions plugin that I've written. If you use Slack, reactions, they are a way to basically comment without actually saying anything, just attach an emoji to something. It looks like this. And this is a very simple plugin, but it will post that reaction to WordPress through HACs, obviously. And it will store that as comment meta. That's it. But I wanted to convert that into using the REST API instead of the admin HACs for the reasons I just told you about. And let's have a look what it looks like. So before we go into what the REST version is, then let's look at the original version that uses the admin HACs. So first piece of the puzzle is this WP localized script, which is just like admin HACs. It doesn't have a lot to do with its name. It can be used in other ways than just to localize scripts. And in this case, we are communicating the URL from the PHP side to the JavaScript to post that reaction into. And well, of course, we could hardcode that into JavaScript, but we aren't bad developers, so we don't do that. There's nothing much more interesting there. Then the JavaScript part is also pretty simple. Here we are posting the reaction using that URL that we just gave it back to WordPress. And we have some parameters for that request as the payload of that post. We have the action which ties into this specific hook in WordPress. I'll show you that a bit later. And then the comment ID, the reaction itself, and the direction of that reaction. And then this is where things get a bit more complicated. The server side code, we have to hook into two different hooks, one for non-logged-in users and one for logged-in users. This is just how admin HACs works. And then we have the bulk of the actual request handler, this function that spans two slides. You don't have to read all, but I'll just point out that it does quite a lot. It sets a header for the content type being JSON. We do some reading data from the post using the helper function that is not described here. We are sanitizing data. We are returning or actually echoing some JSON directly to the response and exiting. And once we finally get to update the comment meta, after that, we'll write some more JSON and remember to exit. Otherwise, the JSON won't be valid. So we have to remember to do a lot of things. But after, I'll describe the same pieces, kind of. So this localized script part, pretty much the same, except that we define this rest namespace here. It's the URL part that will give you some namespace. It's the name of the plugin comment dash reactions slash v1, where the v1 means the version number, which we can then maybe later change without affecting the API if we want to keep serving the old one as well. Other than that, it's basically the same. Instead of giving the HX URL, we are giving the rest URL, in this case, using the getRestUrall function, now in 4.4. And then appending that namespace after that. Also, that's a query part is pretty much the same. With some minor changes, we are obviously calling that rest URL. But then we are appending that slash comment, ID directly to the URL instead of posting that as the post payload. And that is part of the restfulness, kind of the ideology and the concept. And you should look it up if rest is not a familiar concept with you. It's a bit different than just calling functions remotely. But we are also sending some data, the reaction and the action, just like before as the payload. But here, things get more interesting. The server side implementation is kind of split in two. We are registering a rest route first. It's one of those new functions in 4.4. This way, we'll tell the rest API kind of that this is where this endpoint can be found. I'll give it three different parameters. First one being the namespace we defined earlier. The second one being the actual kind of the URL slash comment, slash comment ID. And that's defined in regular expressions. Yet another thing you really need to learn. Well, this is pretty simple in this case, though. And the third one being the bulk of the function call. We are defining the callback, which is the function that will get called if the rest API determines that this request matches this route. And the argument, which are basically the parameters of that route. And we have the ID reaction and action. The ID comes straight from the URL, and rest of it are from the payload. And for each, I'm defining here the validation callback as an inline function. And that function should return true or false. If the parameter is valid, we return true. And if it's false, then the rest API will automatically know that there's something wrong with the call and would also know how to send the proper HTTP response code back. No need to define your own headers or custom JSON. But if it's valid, then we can move on to the next parameter and finally to the callback function. And now the actual handler code is way simpler now, because we don't have to care about if the data that is passed to it is valid or not. We know it's valid. We can just do our business. And on the last line, just return the rest response object with some data that we want to pass to the JavaScript part back. The best practice is to implement all this in a more object-oriented way, implementing this rest controller object by inheriting it. But that's not available if you don't have the rest API plugin installed. And all the same concepts apply. It just has more infrastructure around it, like authentication and permission handling and stuff like that. In summary, use the rest API instead of Admin Ajax. In most cases, it's the better way. It's faster. It's cleaner. And it's both easy to implement and migrate to. Thank you.