That's interesting, thank you Hector for sharing it.
I totally agree we need to provide both headless features and UI-based features, it makes a lot of sense (because headless CMS is not about replacing our current market with another one, it is about adding a new market to our current market).
And that's basically what Plone 5 is providing today: regular Plone is UI based, and plone.restapi provides a pure REST API (and plone.server + plone_client aim to do the same with a different stack).
What does not make sense is the following:
Headless CMSs raise issues of security, as it’s difficult to define which users get which access, creating a risk of delivering confidential content to non-authorized users. Delivering multi-language content requires a lot of development work to re-implement this feature.
Isn't it amazing? If your CMS becomes insecure (or not able to manage multi-language contents) just because you expose its features through an API, it actually means your CMS is very badly architectured. It means its security and its logic are implemented in the presentation layer.
Plone is not like that, so our REST API is:
- at least as secure as regular Plone,
- very resourceful, providing all the CMS features we are used to (multi-language, workflows, etc.).
And as far as I can see, I am not sure it is the case for the other headless CMS approaches and offers.
And it is actually not that surprising if you consider that most of them are SQL-based, and in SQL world, REST API often means "I have connected my db tables to HTTP!!". So yes, then I agree it will be a lot of work to have a running website on top of that, your UI will have to rebuild the navigation, the page composition, even something as simple as the breadcrumb will be very painful to rebuild.
In plone.restapi, we have endpoints for everything we need in any page of our website. I do not think there is any better offer at the moment.