The Content API Gold Rush
While RSS as a technology has offered syndication capabilities for various content management tool since the late 1990's, the idea of reuse of content from a repository across various channels is again novel. Sure enough, the current crop is more elegant and provides remote content manipulation functionalities, something that RSS/ATOM obviously don't.
The first movers in this new wave of Content APIs were hosted services, know as CaaS (Content as a Service) platforms. More traditional monolithic WCMSes started adopting REST APIs, with popular LAMP products like Drupal and WordPress catching up by shipping with a RESTful API in late 2015.
In addition, there are a number of API Platforms, providing an abstraction directly a database, with PostgREST being the extreme and only offering a very thin layer ontop of the PostgreSQL RBDMS.
Full Service CaaS Platforms
Full service CaaS platforms allow you to pay a fee for a content repository that is hosted somewhere on the cloud. They take full responsibility for your hosting and maintenance, making that your content is available via their API at any point in time.
Some well known companies working in this space are Prismic and Contentful. They both boast excellent developer documentation, ready-to-use integrations to popular static site generators, "endless" capacity and a whole lot more - all for a very reasonable price.
These platforms are generally very well marketed and productised - making them an appealing option for many. But for long running projects where flexibility and integrations might be needed the black box approach might be limiting:
First, the customization demanded by the client’s requirements seemed too complex to handle with a service where making alteration on the code level wasn’t possible. Second, the customer thought they might need an integration to an existing SSO-service for logging in to content management.
- CMS done right, vol. 1
Also while you can export your content from these services, with each REST API being a different beast, you might end up locking yourself to their specific API - with changing being cost prohibitive. One option is that the CaaS provider will go out of business:
With many developers now scrambling to move their apps away from Parse, the developer platform service model comes under fire as well. Can you trust your platform of choice, or will they close shop on you tomorrow?
- The real reasons why Parse shut down
So considering something like a Hexagonal Architecture from the very first steps you start using any Content API is very much recommended. You'll want to have some level of abstraction to make it possible to switch between APIs.
RESTful Content Management Systems
LAMP CMSes still make the web go round. Each day you're likely to be a PHP user through CMSes like Joomla!, eZ Platform, Typo3 or some other popular products. Many of these originate from the early 2000's and RESTful APIs are a relatively recent addition.
CMSes now expose quite a bit of their functionality. Catering for fat clients running on the browser, static generators or slick simple but effective content relays built with Node.js is something that is done out there in regular offices around the world.
Technically you can consider a RESTful CMS as a self-hosted CaaS, which gives you the power that a CaaS Platform has but also allows for more flexibility. This is true, but for many users a Content Management System is much more than a collection of forms to create content:
The content creator will need to know the context in which the content will be used to create remarkable content! It will be all about adapting to the context and providing the tools for all the stakeholders to deal with that adaptive nature of CaaS.
- The Promises, Challenges and Opportunities of Content as a Service
People are used to managing their site structure with navigation, layout building, feedback forms, eCommerce store discount management and more. Let's say a customer would be used to doing all of this with the Concrete5's editing interface. Without proper integration for the REST API to allow the same workflow you're taking features away from the user.
If you build a website with only using the Content API, then you'll need to evaluate what will take the place of that tool. Will you spend time in building a separate Site Management Interface? Will editing require quite specific know how of what levers to pull to make content appear on a certain location?
The above questions quickly lead to the question that what was the point of this "headless website" anyhow? The visitors and editors of a site do not (and need not) care how the site is built.
In addition the danger of loosing focus in any industry by thinking too grandiose is a real threat to any product:
WordPress wants to be THE operating system of the internet, like microsoft is THE OS for computers, Google is the defacto Search, WP will be the defacto OS for Internet where most published thoughts will be published through WP, all controlled by a single entity powered for free by the community.
- It’s official, we’ve been blacklisted by Matt / WordPress (comment)
I'm not saying WordPress is going to experience a downfall, but realistically thinking no WCMS should become "The Operating System of the Internet". So while WordPress could power your fridge or some other realistic IoT scenario, there are probably better options.
API Platforms
API Platforms (or BaaS') are elegant, purpose built frameworks for spitting out data structures JSON. There are a number of options written in different programming languages like Deployd for JavaScript and BAASBOX for Java.
For PHP the forerunner is ProcessWire, but more contemporary options are HOOK and API-Platform. Both HOOK and API platform allow you to build custom backends with RESTful APIs without too much coding work:
API Platform is a brand new set of tools to kickstart modern web projects. It’s a framework for API-first projects built on top of Symfony. Like other modern frameworks such as Zend Framework and Symfony, it’s both a full-stack all-in-one framework and a set of independent PHP components and bundles that can be used separately.
- Introducing API Platform: the next generation PHP web framework
API Platforms are probably the most appealing options for developers. They offer the cleanest technical implementation "done right", but that's also their limitation. While CMSes can be bloated products with plenty of useless features, they've also been molded over time through real needs and use cases.
Multilingual capabilities, content management and modelling functionalities are not a trivial matter and might be where developer oriented platforms can become a burden to modify and upgrade over time. In additional trivial things like a media gallery might require an unreasonable amount of work compared to what a CMS gives out-of-the-box.
Conclusion
Hosted CaaS options might be the perfect fit when you know that all you need is a reliable content storage where content creation is done in a separate silo. For a flat fee you'll get a constantly evolving platform with interesting features:
Linked entries querying: multiple requests for entries which are linked with other entries can be put into one request. That's a great way to optimize performance, especially on mobile devices.
- Under the Hood [Contentful]
For CMSes it's probably best to go with a hybrid approach; leveraging the complementary site management) features offered by the system, but using the RESTful APIs where appropriate to provide richer experiences and powering other applications.
API Platforms allow for high velocity development and are probably well suited for startups or other use cases where the stored information can be considered "data", not "content". Slapping on a WYSIWYG editor with features that people expect from a WCMS might be surprisingly difficult.
As with most things, there is no single right answer. Likely you'll have some combination of these or to invest in a technology like Symfony and PHP and build on top of that, for example by using eZ Platform as a Symfony Integration Platform.
For me the ideal option now is rolling your own CaaS with a CMS built on a framework and hosted hosted on Google App Engine or a similar service. This allows stability and leaves options open for deep integrations and enriching your Content API with other data models or extracting new insights from your content with a Graph Database.
Which ever approach you take, be sure to abstract for changing your content repository from day one in your target application, be it built with Angular, React, Metalsmith or something completely different.