Your CMS REST API should be WordPress Compatible
In the 1980s there was a thriving market in personal computing with brands such as Apple, Atari, IBM, Commodore, Spectrum, Tandy and multiple others. All of these manufacturers worked hard to top each other. These products were closed and had little to do with each other, each sporting a different operating system, display outputs and so on.
The breakthrough for personal computing came when companies like Columbia Data Products and Compaq reverse engineered the IBM PC, creating a flood of PC compatible hardware. This was the first wave of open computing, driving down computer prices whilst accelerating innovation.
Partly thanks to this the late 1980s and early 1990s was a time when your new computer was faster, in the orders of magnitude faster, than the one you bought two years ago. Great times, sigh.
So what's that got to do with anything?
Nice trip down the memory lane, bro, but what's that got to do with WordPress and the rainbow filled world of Open Source and love? History has a tendency of repeating itself and the WordPresses, Drupals and Joomlas may be the Ataris, Tandys and Spectrums of tomorrow.
Each of these content management systems are succesful in their own right, but at the same time they remain very closed and detached from each other. Sure they share some common technologies like PHP, JSON and RSS - but they're all thriving to be the best option in something that is a very common need.
In the last few months the head honchos of these dominant Content Management Systems have increasingly started talking about decoupling by offering public APIs. Driving this decoupling to the mind of the general public is great, but it does not serve for creation of any kind of interoperable standards.
RESTful APIs are a vague concept. But it's a nice pair of words to repeat and prove your application embraces the world with open arms. WordPress.com is now using it's own API to power WordPress Calypso, an open source content editing interface and the Drupal lead also reacted to this by toying with the idea of a similar shell.
Both of these initiatives must have been, in part, sparked by content platform players like Contentful, Prismic and Medium. All of these offer APIs that allow you to work with content and forget about database abstractions such mundane things.
The closed content repository Medium has even go high profile Open Source heroes such as the creators of Ruby on Rails on it's list of users:
Yes, we’re well capable of technically making a great blog system, keeping it updated, and keeping the design fresh, but it falls to the bottom of the list of priorities against making Basecamp better.
-- Signal v. Noise moves to Medium
The above quote underlines what is going on here. Basecamp is not in it to create a blogging platform. It has no return for them. Similarly investment in the investment in the core content management repository has diminishing returns. What'll you have in your next version? Better tagging, higher limit of versions, better search?
There is room to improve upon all of these, but why go at it alone? Why create your own disk format or proprietary joystic port? Why not just implement your content repository to a specification like JSR-283 in the form of PHPCR. Because life is life and the Betamaxes don't always win.
Just look at MySQL for what we need
Somewhere around the time of acquisitions of MySQL by Sun, alternative options like MariaDB and Percona came into existence. The key feature that they offered was MySQL compatibility. They are drop in replacements for MySQL - something that is not really a standard, but a common tool used by millions of people.
Instead of worrying about adding support for new databases, WordPress developers can easily switch between these options. This is all driving the whole field forward, as can be seen from the recent advancements in MySQL. This in turn improves performance and adds capabilities for CMSes using MySQL.
Many CMSes remain as monolithic abstractions of a relational database and a coupled crud for that. WordPress Calypso was the first large project to make a significant effort of moving away from the tight technical coupling.
As long as there is no shared API between different content management tools, the different "decoupled" shells and repositories remain exclusive. There probably are specifications and reference implementations of suitable APIs gathering dust around there.
The dominance of WordPress is such that we should just adopt the WordPress REST API as a blueprint. WordPress is the MS-DOS of the web. And Automattic has just announced Windows 3.11 that'll runs only on it and not on DR-DOS, for example.
The API probably has some warts, but those need to be accepted and we need a uniform way to extend the standard (like SVGA was to VGA). MySQL is not a standard and can be extended with features such as JSON support by Oracle and the community.
If these extension is good and universally needed, then it'll naturally become a de-facto standard. And in the meanwhile you're only slightly locked to the MySQL implementation with support for this specific feature. For CMS APIs a faceted search could an example of such an extended feature that WordPress does not currently offer.
Content repo agnostic UIs where are thou?
In addition to MySQL there are examples like SPDY and React.js where standard implementations have been lacking and have been picked up, and even standardised in the form of HTTP/2, because they've been good and practical solutions to real life projects.
The benefits for CMS users and developers would be the ability to switch between storage backends more fluently. A content repository agnostic content editing shell could start by offering an alternative interface to the official WordPress backend. Imagine querying Drupal or WordPress databases with identical GraphQL queries.
By using an alternative backend you could gain more features and performance provided by a content repository with a graph database, for example. Individual CMSes could also be fitted with API adapter that could make it possible to use Drupal with Calypso, for example.
The end result would be increased innovation, added choice and freedom. Just as with switching a hard drive to an SSD, there is essentially no fundamental difference for the end user. An SSD is "the same, just better".
Mass storage is abstraction of storing data to a medium, just as with different CMSes should be. I can keep on using Linux, OS X or Windows regardless of whether I'm on an HDD or an SSD. I'd like to swap CMS interfaces and repositories in a similar way.
So the next time you start creating a CMS with your own REST API, why not just curl some WordPress.com requests and use those as your spec? Of if you've got a REST API, take a look at how hard would it be to make it run WordPress Calypso by adapting WPCOM.JS.