The sheer volume of WordPress REST API articles, lectures and even specialized conferences (!) could easily blow you away, looking like a cutthroat new technology, standing side-by-side to web applications that can run only on the newest version of Chrome…
But the reality is on the other end of the spectrum. While REST API existed as a plugin from early 2013, its introduction into the core happened with WordPress version 4.4, that is, in late 2015. And this is not the whole story. REST endpoints are not included in the core (yet) so developers still need a plugin to utilize its methods in making their next modern web application. If you’re scratching your head right now and can’t make heads or tails out of this introduction, relax and click back to the excellent article by Tom Ewer on introduction to WP REST API.
So why is the reality on the other end of the spectrum? If you have read our first article in this series, an overview of WordCamp Vienna, you probably glimpsed through Gábor Hojtsy’s presentation (a Drupal multilanguage component developer) who explained that Drupal includes REST API for 8 years now! Seems like WordPress has a lot of catching up to do, but this wave of changes is building up at the right time. And the timing for this overview is perfect as WordCamp NYC (15th to 17th July 2016.) was also filled with lectures connected to this topic.
Here are a couple of ideas on REST technology and its importance to the WordPress ecosystem that could be overheard in halls and lecture rooms at the extraterritorial UN building:
1. Evolution of core functions
Current community talks about compatibility, stability and new features that are somewhat in a status quo. WordPress ecosystem needs to cater to 7% of old websites that utilize PHP 5.2 and the due date of removing this compatibility is not clear. It’s hard to push new functions and progress with this kind of weight around your neck. WordCamp NYC hosted a neat lecture by Mike Schroder (@GetSource), who explained the whole WP release lifecycle from first-hand experience (Mike was the release lead for 4.5). One major takeaway was that component lead developers are key to release success (as they are the ones with deep knowledge of WP core) and second, it’s not always trivial to push everybody in the same development direction.
REST API will place a flexible layer on top of that rigid core and provide parallel ways for evolving WordPress capabilities. We’re not stuck on implementing richer functions and interactions, and as you will see in the last point of this article, we can code with even better load time performances in mind.
2. WordPress as a backend
Adam Silverstein (@roundearth) from 10Up gave an excellent talk at WordCamp NYC exclusively on this topic, explaining how to utilize Backbone.js for building an app that has WordPress as a backend. Unfortunately, there are no videos from this session so have a look at his similar lecture from WordCamp US held on December 2015.
Developers can even deploy static HTML, CSS and JS files to AWS S3 and let them communicate via REST API to fetch new posts, products or other custom post types. This type of application hosting is powerful and the cheapest one available. (Staticpress plugin will help you with this kind of projects). Finally, all of the world’s developers would be able to talk “WordPress” as they will utilize their own knowledge, programming language and experience from their own frameworks and IDEs.
3. WordPress as a service
WordPress as a service is a similar concept as using WP as a backend, but with these methods, you’re utilizing WordPress to act like a worker in your whole IT orchestration. Think of it as a data and business layer that can perform various calculations, cron jobs and backend tasks that run on some event that happened in your other parts of the system. For instance, you could build an image processing thread in WordPress and let it work for you in the background, while other parts of your IT system take care of the interactions and user experience.
Eugene Estrati (@eistrati) gave a lecture during the first day of WCNYC on this exact topic and he even spiced things up using AWS Lambda and other modern AWS cloud examples. You can easily slide through his presentation here…
Bonus hint: Steve Bruner (@sbruner) gave a business-oriented talk on using WP as a service for specific business purposes – ERP, CRM, CRON, Scheduled billing, etc. You should check his slides if you’re interested in optimizing Custom Post Types and Advanced Custom Fields for these kinds of applications.
4. Connect WP (WordPress as a platform)
Now here is one interesting concept taken from your favorite torrents. If WordPress is used on 25% of the current internet, why not use it as a distributed peer-to-peer system where every site can communicate and connect individually on a mesh-type system. You would get a true platform of connected dots, each representing a computational node in this globally distributed system, all powered by REST API. The possibilities with this kind of system are endless and Gerry Pendergast elaborated it fully in this video:
Gary talked (at WordCamp Europe) about using Connect WP for security, trust networks, p2p messaging, and trusted curators cases, but there is also one important function that Ryan Mccue describes in his article on the future of REST API – it’s called the authentication broker and it could give decentralized WordPress sites a way to get user authentification through WordPress.org account
5. Performant RESTful themes
I didn’t touch on one of the most stable and usual talks in the WordPress ecosystem – Themes! Every developer had various experiences with them, both good and bad, both freemium and premium. You know the drill – developer needs to build page, post, footer, header template, etc. – code everything with HTML, CSS, JS and PHP in mind, combine it in a way that is both responsive, adaptive, accessible, compatible, fast and updateable. But most of this technology is still PHP, WP API and MySQL. With REST API this can be different (and better).
Developers could build a theme that communicates with the database only through REST API. First, they will get performance benefits that go over 15% of speed improvement. Folks from Delicious Brains (authors of excellent DB Migrate Pro plugin) wrote an extensive article on REST API vs ADMIN AJAX WordPress performance so you can read the whole case study on their blog, but in short, here are some of the conclusions of the performance load for 100 virtual users.
Performance benefits sprung out from a completely different loading mechanism which the article clearly explains and there is one additional moment – with this modular approach to utilizing the datasets, you can load content only when you need it and only where you need it. The first place to start is to use Backbone.js (head back to point 2 if you want to find out more), but there is an alternative approach to using React + Redux on the front end to build a RESTful theme. This was the talk of Kelly Dwan ( @ryelle ) in which she presented examples of utilizing React library to build modern JS WP interfaces. Check her slides from Wordcamp NYC here.