Are you going to the APIStrat Conference in Nashville, or the API City Conference in Seattle?

Headless CMS And The API Evolution Beyond WordPress

I am a fan of what WordPress has done for the online world. I feel like it has enabled a lot of folks to take some control over their web presence, and in some situations even made programmers out of business people who never thought that is what they’d end up doing. Even with all the positive benefits of WordPress, it has had some significant negative side effects which I think warrant us to begin looking beyond the existing ecosystem–something I’m hoping the headless CMS, and static website movement can help fuel. I’m not anti-WordPress, but I think the movement has run its course, and we can do better when it comes to helping folks take control over their web presence, as well as avoid much of the security challenges we experience as a result of WordPress.

If you aren’t familiar with the concept of headless, it is just about doing APIs, but centered around the end deliverable–the application. Headless focuses on decoupling content for use in apps, websites, or any other data-driven projects, allowing content to be created and managed independently from where it’s used. To us API-aware folks this is how All applications should behave, but I feel like the headless CMS concept is an important API gateway for business users who have drank the WordPress kool-aid, and are looking to do more with their CMS, and break free of some of the challenges of operating exclusively in a WordPress state of mind.

The most damaging aspect of WordPress I have felt is it’s emphasis on the blog. Everything is centered around the blog with WordPress installs, which isn’t the reason many folks should be doing a website in the first place, but because of their platform they feel compelled to. Headless CMS can be about managing ANY content, and crafting an API backend, that can deliver exactly the content you need in any website, web or mobile backend, bypassing the concept of the blog entirely. Which may not seem like much, but I’ve seen the blog become a pretty big obstacle for some individuals and companies looking to get a handle on their digital content.

The second most challenging aspect of operating WordPress is security. Managing a dynamically driven CMS that is so ubiquitous, and ultimately a huge target by bad actors is daunting for any seasoned IT people, but can be damaging for any unaware individual just trying to manage their website. I stopped running API Evangelist on WordPress because I couldn’t keep up with the security concerns, and operating my public presence as a series of statically published websites has done wonders to the security of my platform. I just do not feel that WordPress is sustainable as a CMS for individuals and companies who do not have the resources to properly manage and secure. There are many flavors of headless CMS, I’m looking to push the more static flavor I’be been seeing on the landscape.

I’m hopeful that the concept of headless coupled with a static CMS can be a proper gateway for individuals, companies, organizations, institutions, and government agencies who want to get a handle on a specific layer of managing their data and content, to learn about APIs. I find that most people aren’t interested in learning about APIs, they are interested in delivering API-driven solutions. Once they get a taste of this, they want to learn more. I feel like the WordPress API is going to be a complicated introduction to the world of APIs for many, but a simple, static, website implementation with a robust API backend provides a much more approachable view of what APIs can do. I’m going to keep an eye on everything headless, and keep scratching out stories to tel my audience about what they can do. I feel like they are key to helping us evolve beyond the Web 2.0 world WordPress set into motion, and begins to give us more control over our backends using APIs, but in a way that help us manage many different front-end applications, with CMS being the first stop for many individuals.