Custom Endpoints with the WP REST API

Why would you need to use the WordPress REST API? I recently started collaborating with my father. He’s built a bunch of sites using WordPress and Divi, but sometimes comes up against the limitations of that solution. One of his passion projects is a site to help people who are struggling with bullying, but he needed a web app section to help guide users to solutions. I built a plugin that would accept data as csv files on the backend, and then process that into shortcodes which could still be used within the Divi framework. It then used ajax calls to make some of the data interactive, and used session storage to persist state across multiple pages. So far so good.

But the app sprawls a bit, and the mix of solutions felt a little messy and slow. So I wondered if I could build a single page app, and explore React in conjunction with WordPress. I’ve never worked with React, so I’m on a bit of a learning curve. Once I’ve finished this process, I’ll reflect more on how I integrated these two things (if it’s successful!). The first step though was to set up custom endpoints using the WP REST API. I was surprised at how intuitive and powerful this process is.

The essentials of REST is that you can send a request to a server via a particular URl, or endpoint, and get a resource as a response. What this means for WordPress is that we can decouple the frontend and the backend. I can use the power and familiarity of WordPress’s admin area but use a different frontend, React in this case, to consume that data.

WordPress has default endpoints built in (Gutenberg uses these, for instance). It’s easy though, to set up custom endpoints:

<?php
add_action( 'rest_api_init', function () {
  register_rest_route( 'backchat/v1', '/form/(?P<id>\d+)', array(
    'methods' => 'GET',
    'callback' => 'backchat_rest',
  ) );
} );

Stepping through this, we first hook into the Rest API, then register the route. This accepts three parameters. The first bit is the base, which namespaces your route and prevents clashes with other endpoints. This is generally versioned so that if you’re needing to make sweeping changes to how your endpoints work, you can reversion it. In my case, where I’m essentially consuming the data internally this isn’t immediately important. The second bit defines the actual route, and the parameters it will accept. In this case the route is form, and the parameter is ‘id’ with an accepted value defined by regex, \d+, accepting only digits. Regex is a whole other skill, but I essentially cut and paste this one. The third bit is a set of options, most importantly a HTTP method, and a callback function. You can also add validation and sanitisation callbacks, and control permissions.

The callback function looks something like this

<?php
function backchat_rest($data){
    $form = $data[‘id’];
    */Use $form to access my custom tables in the DB */
    return $something
}

Then when you fetch the URL example.co.za/wp-json/backchat/v1/form/1, $something will be converted to JSON and returned. Super powerful!

Notebook