Posted on July 13, 2016 by: Mike Grotton, Front-End Developer
Since its introduction as a branch of trendsetting blogging software b2/cafelog, WordPress has evolved to become much more than just a tool for fledgling writers to easily get their thoughts and opinions onto the web browsers of the world. As any diehard WordPress developer will tell you, the platform has evolved to be a mostly fully functioning framework for just about any web application you can imagine. Yes, I said mostly. The WordPress code landscape lacks one feature that has prevented the platform from becoming a true framework, but that is about to change and, in fact, has been slowly changing for the past few years now. An emerging feature is coming to WordPress that will expand its capabilities and likely will advance it into the toolbox of web application developers everywhere.
What is it that WordPress can’t do, exactly?
I’ll admit I’m a bit of a snob when it comes to WordPress’ versatility. I’ve never run into a particular project that couldn’t be done on WordPress, and I’m constantly surprised by what I see other developers accomplish with it. So if you’re a WordPress developer and bristling at the suggestion it has limitations, I feel you – but the harsh truth is, WordPress is way too into itself to be a serious part of the framework community.
REST, or more specifically a REST API, in its purest form uses the components of HTTP to pass information, function and oh so much more within the request life cycle before, while and after it is taking place. There are many ways to accomplish this outside REST, but REST won the standards war when it came to web application development. And standards matter.
So to answer that question of what WordPress can’t do? It can’t do REST. I can hear WordPress zealots shouting from their proverbial rooftops now: “Yes it can!” However…remember these words: “standards matter.” There are plenty of ways to give WordPress REST capabilities, but until they are a part of the functional core, WordPress does not have that capability, and that has held it back from entering the wider world of web application development.
One of the biggest advantages of a REST architecture is the ability to combine function, data and so much more in a fluid way that does not present any ramifications for the central project. As applications combining the functions of, say, osCommerce with WordPress in a way where they both occupy the same page and impact one another through back-end or front-end interactions is, while not impossible, daunting.
Since both depend on a complete “life cycle” of their own to create a page, custom code has to be injected in each application’s life cycle to form the interaction. For instance, if we had a store with product categories and, as the category was changed, we populated a list of WordPress posts from a matching category in real time, the process is, again, not impossible but extremely tedious. One application has to be the source of “truth” for the page proper, and the other has to be a servant. Without REST, custom code has to be written for the servant to both handle the request and return the result. What if you want the “posts” to be served by WordPress? You might have to deal with “rewrite” issues affecting which application has control over processing URLs. The logistics become a nightmare, and your resulting project now carries a maintenance penalty. If you’re a client who bought a website, just wait until one of these two applications updates and breaks everything.
With “components” that provide data via the REST architecture, the task is extraordinarily simple. In the scenario above, our project controls which “slice” of the life cycle each component executes, and when. Neither component is controlling delivery of the page itself. Our project is able to ask each one for what it wants and put it together just how we like it.
So What Does This Mean for WordPress and Web Application Development?
In truth, nobody knows for sure, because the possibilities are so huge. WordPress achieved its status as the most used content management system (CMS) in the world because of the developer-friendly codebase and the ability to create endless customized data collections and the taxonomies to connect them. Sure, we use the word “post” a lot, but WordPress has long moved past being a blog-only platform. It is, regardless of its missing REST, an application platform. Odds are, if you need to organize some data with specific properties and attributes, you can do it easier with WordPress than with any other framework out there.
Without REST, though, WordPress wants to be the star of the show. How much you can take advantage of WordPress’ capabilities outside of WordPress depends on how much you want to trust code that is not “core” to the platform and therefore prone to breakage. Or how much time and money you want to invest in hiring a developer to “build a bridge.”
Progress on integrating the REST API into the core of WordPress has been slow. Like many core add-ons, the REST API is being developed as a plugin. Yes, you can have REST now, but one look at the “breaking changes” list from version to version should convince you otherwise.
The first major move toward integration was achieved in WordPress 4.4 (4.6 is in Beta) when the API framework was added to the core. If you have 4.4 (or hopefully something higher) powering your site, you have part of the REST API sleeping inside. The integration of the API framework was a major coup simply because it allows third-party developers to make their themes or plugins API-capable. Without the “endpoint” – the part that actually makes the magic happen – it’s all just wishful thinking.
The current plan has endpoint integration happening with WordPress 4.7, if the WordPress overlords approve the work. With 3-5 months between major version releases, that puts the API release into early 2017, or late 2016 if you’re really optimistic.