Many companies today are known for their APIs. When Twitter launched its API, thousands of desktop apps, mobile apps, and clients built on top of it. Stripe focuses its business exclusively on making payments and subscriptions available to other businesses through its API.
WordPress, the open source publishing software we use at Fusion, has a project to launch its own RESTful API – WP-API. As the project has progressed, it’s become a bit of an “everything to everyone” prospect. We’d like to take you through some ways we think WP-API will be a foundational, game-changing technology for us.
1. Content analytics
The big two analytics tools, Omniture and Google Analytics, were built with e-commerce in mind. Publishers can use conversion funnels to understand how users are engaging with their sites, but it’s less than ideal.
On the technology team, one of our missions is to ensure everyone at Fusion has access to the analytical data they need to form insights. Getting from here to there is a multi-step process:
- Collect the data. For Fusion, this is Google Analytics Premium and all of the metadata about our content stored in WordPress.
- Make the data easily query-able. The easier it is to query, the faster we’ll be able to operate. Emphasis on easy.
- Explore the data for insights. Slice and dice the data in various ways to identify the outliers. Dive into the outliers to see if there’s anything interesting. Rinse and repeat.
Backed by Elasticsearch, WP-API will let Fusion query its content by arbitrary attributes — for instance, word count, number of images, or video length. It’s a step up because we won’t have to encode this metadata as custom Google Analytics attributes, which are limited. Once we have this technology in place, we’ll be able to more easily, say, segment our KPIs and promotional efforts by narrative, or offer realtime suggestions like “this story is spiking, but it’s not being promoted on the homepage. Should we put it there?”
2. Test-driven design
Optimizely is a service to test design, text, and other UI components. When you set up an experiment, you configure a control group and one or more test groups. The experiment runs until it’s reached a statistically significant conclusion. We’re increasingly using Optimizely to validate our product decisions before they go to production.
However, our tests currently are limited to reusing data on the page. In a worst-case scenario, we can dump a JSON blob into the page and use it for just the test.
In the real future of WP-API, we’ll be able to pull our data directly from the API for our tests — no representation on the page needed.
3. Single-serving apps
When someone hears about an API, they may immediately think, “oh, mobile apps.” And while mobile apps are quite shiny, the opportunity is actually quite larger.
Single-serving applications, regardless of whether they’re on iOS, Android, or the web, represent less development effort for more experiments. In the engineering world, this technology strategy is known as a “services-oriented architecture”, or one where we can build functionality to meet editorial and business needs without WordPress becoming a monolithic codebase. It also means this functionality can fail gracefully too — if a secondary feature goes down because of a bug, it doesn’t need to take WordPress down with it.
Let’s bring this back to the real world. Fusion recently had an SEO audit where the firm recommended we add
rel=nofollow to links with a domain authority score less than 80. We don’t want to make editorial look this up every time they add a link. We could build this process into WordPress, but it increases the complexity of our codebase and, subsequently, likelihood of failure. With WP-API, we can build a middleware application to crawl through all of our content on a monthly basis, identify all domains linked to in a given post, and add or remove
rel=nofollow as needed. If it goes down for some amount of time, not a problem — it’s a secondary feature on our platform.
4. Manage WP state
If you’re not a developer, you may want to skip to the next item. We’re diving deep 😄.
A forever problem of development at a media company is having enough data locally to accurately represent production. Aside from getting a copy of the production database, which poses its own set of problems, there isn’t an easy way in WordPress to get a representative set of data with the important site configuration details.
Dictator is a WP-CLI command to give developers the ability to “control the state of WordPress.” Inspired by Puppet and Salt, server provisioning tools which store server state in configuration files, Dictator stores, applies, and diffs WordPress state.
However, the project ran into a fatal flaw: WordPress doesn’t have a well-defined schema. With WP-API, though, we’re defining schema for each of WordPress’ internal resources. This schema will be usable to foster projects like Dictator.
5. WP REST API
Ultimately, WP-API represents a fundamentally important shift in how the world works with WordPress. WordPress’ internal APIs are notorious for their technical idiosyncrasies, which stem from architectural decisions made over 11+ years.
WP-API is an opportunity to redesign how the world interfaces with WordPress. And, hopefully, apply lessons learned from the past.