 Hey there, and welcome to Learn WordPress. In this tutorial, you're going to learn about the WordPress REST API and how to use it in your projects. You will learn about key REST API concepts like routes, endpoints, and global parameters, as well as how to use it in places something like AdminAgeX. The WordPress REST API provides an interface for applications to interact with a WordPress site. These applications could be WordPress plugins, themes, or custom applications that need to access WordPress site data. One of the most well-known implementations of the REST API is the Block Editor, which is a JavaScript application that interacts with WordPress data through the REST API. An API is an application programming interface. It's a set of functions that allow applications to interact with each other. WordPress has many different APIs. The REST API is just one of them. REST stands for Representational State Transfer, which is a software architectural style that describes a uniform interface between physically separate components. At its core, the WordPress REST API provides REST endpoints or URLs, which represent the posts, pages, taxonomies, and other built-in WordPress data types. Your code can send and receive data as JavaScript object notation or JSON to these endpoints to query, modify, and create content on your site. Let's dive into some of these concepts to understand them better. In the context of the WordPress REST API, a root is a URI which can be mapped to different HTTP methods. An HTTP method is the type of request that's made whenever you interact with anything on the web. For example, when you browse to a URL on the web, a GET request is made to the server to request the data. When you submit a form, a post request is made, which passes the submitted form data to the web zoom. The mapping of individual HTTP methods to a root is known as an endpoint. Let's look at some examples of roots and endpoints. If you open a browser and go to the wp-json URL of your local WordPress installed, you will be making a GET request to that URI. The data returned is a JSON response showing what roots are available and what endpoints are available within each root. By default, your browser will display the JSON data in its raw data format. To convert it to a more readable format, you can use a browser extension like JSONFormatter for Chrome, basic JSONFormatter for Firefox, or JSONP for Safari. In this example, WJSON is a root, and when that root receives a GET request, it's handled by the endpoint which displays the data. This data is what is known as the index for the WordPress REST API. By contrast, the wp-json-wp-v2-post-root offers a GET endpoint, which returns a list of posts, but also a post endpoint. If you are an authenticated user and you submit the right data via a post request to this root, the request is handled by the endpoint which creates new posts. Typically, the same root will have different endpoints for different HTTP methods, including GET for fetching data, POST for creating data, and DELETE for deleting data. The WordPress REST API includes a number of global parameters which control how the API handles the request and response handling. These operate at a layer above the actual resources themselves and are available on all resources. Global parameters are implemented on the REST API roots as query string parameters. Query strings start with a question mark and are followed by a series of key value pairs separated by an ampersand. Take a look at the wp-v2-post-root you looked at earlier. As you can see, the default is to return all the available fields for a post. However, if you update the root by adding the fields global parameter, question mark, underscore fields, and then specify the fields you want to return, in this case author, ID, excerpt, title, and link, you will see that only the fields you have requested to be returned in the response are made available. The WordPress REST API also supports pagination and ordering of results. Pagination is handled by the per underscore page, page, and offset parameters. For example, you can update the post-root to return only five posts per page by adding the per page parameter to the root. It's also possible to order the results using the order and order by parameters. For example, you can update the post-root to order by post-title in descending order. By default, the WordPress REST API uses the same cookie-based authentication method as when you log into the WordPress dashboard. So for REST API endpoints that require a valid user, if the authentication cookie is present, the request is authenticated. However, it's also possible to use application passwords, JSON web tokens, and OAuth 1.0 to authenticate requests. We will cover these authentication methods in a future tutorial. One of the biggest benefits of using the REST API in your plugins is that you can replace your admin Ajax requests using less code and making your requests more secure. To see this in action, let's take a look at a simplified example. In this code, the plugin adds a menu page to the WordPress dashboard. The page has a button and a text area, and when the button is clicked an Ajax request is made to get the most recent posts and display their titles in the text area. Besides the functionality to render the admin page, this is what the code looks like to implement Ajax. First, in the wp-learn-rest-nq-script function, you need to use the wp-localize-script function to pass the Ajax URL to the wp-learn-ajax object so that it's available when the script is loaded. Note that in this example, there's no implementation of a non-super security, but it is recommended for a production plugin. Then you need to add a callback function to process the Ajax request by hooking into a wp-underscore-ajax-underscore-action-hook. On the JavaScript side, some JavaScript will be needed to handle the click event on the button and make the Ajax request. Historically, this is usually handled using some jQuery. So what would this look like if you were using the WordPress REST API? First of all, you don't need to pass that Ajax URL anyway, so we can remove that code from the nq-script function. We also, when we're processing an Ajax request, so we can move the wp-learn-ajax-fish-post function and associated hook. Finally, we can remove the button and add one to load post by the REST API. WordPress ships with a backbone JavaScript client for making direct requests to the WordPress REST API. This provides an interface for the WordPress REST API by providing backbone models and collections for all endpoints exposed through the API. To ensure that your code is able to use the backbone JS client, you need to update your plugin's JavaScript dependencies from jQuery to wp-an API. So we can just change this to wp-an. This will ensure that your plugin's JavaScript code is only loaded after the REST API JavaScript client is loaded, so you can use it in your plugin. In the JavaScript file, first you can delete the jQuery Ajax related code. Then you'll want to start by registering a click event handler for the new button. So we can do something like const load post by REST button and we'll say document get element by ID and we will pass in the learn REST API button ID of the element and then we want to just do a check just to make sure that we're only running our code if that button exists and then we can say load post by REST button add event listener add that in the click event and register the callback function to fire when the button is clicked. Then in this new event handler function, you can use the wp-api client by accessing it from the global wp object to create a new collection of posts. Here we can say const all posts new api collections posts. At this point, all posts is simply an empty collection, so you will need to fetch the posts by calling the fetch method on the collection. So all posts fetch. The fetch method returns a prompt, so you can chain a done method to handle the response to implement a callback function which will accept the response from the api request. Done, a callback function. You can specify a post argument in this callback function to accept the response from the api request. So here we can say posts. Now you can loop through the post object using the for each method and access each post individually. You can say posts for each another callback function. You can pass the individual post into post as an argument. Finally, you can add the post title to the text area. First, you need to create an instance of the text area before the for each loop and then append the post title to the text area's value property inside the for each loop. So we'll start with the const text area and say document get element by id and its id is wp-learn-posts. And then inside the for each loop, we can say text area dot value and then append it to the existing value and append post title rendered. And then also append a new line character so they're not all next to each other. Let's see what this looks like when we refresh this page in the front end and let's load posts by rest. The great advantage of using the WordPress REST API and the Backbone.js JavaScript client is that you can use the same client over and over again. For example, if you wanted to fetch users, you could simply create a new collection of users to fetch them. To do this via admin Ajax, you either need a new admin Ajax handler function or you'd need to update your existing function to accept a parameter to determine what to fetch. The other advantage is that the API client handles non-checking for you. With admin Ajax, you have to specify this yourself and check it in your handler function. So using the REST API and the JavaScript client makes your requests more secure. This tutorial just scratches the surface of what is possible with the WordPress REST API. To learn more about how it works, how to use it and how to extend it, check out the WP REST API handbook documentation in the developer resources on WordPress.org. Happy coding!