The way I understand it is that a headless CMS shouldn't be built in a way that it's limited to how content can be delivered. It should be built so it can be called easily using various methods, whether you're trying to display the info in an app, on a website, etc.
A decoupled CMS likely has a specific front-end presentation layer that is built and housed separately from the back-end.
For example, if you wanted to build a website using Gatsby (or any static site generator) on the front-end but use WordPress as your back-end, it would be a decoupled CMS. This is because the WordPress API is built on top of something that is primarily geared towards displaying information on websites.
Many traditional CMSs (WordPress, Drupal, etc.) are adding APIs on top of what they already have so users have the option to use traditional or decoupled. But headless CMSs typically use APIs exclusively to deliver content, there is no traditional/coupled option.
The way I understand it is that a headless CMS shouldn't be built in a way that it's limited to how content can be delivered. It should be built so it can be called easily using various methods, whether you're trying to display the info in an app, on a website, etc.
A decoupled CMS likely has a specific front-end presentation layer that is built and housed separately from the back-end.
For example, if you wanted to build a website using Gatsby (or any static site generator) on the front-end but use WordPress as your back-end, it would be a decoupled CMS. This is because the WordPress API is built on top of something that is primarily geared towards displaying information on websites.
Many traditional CMSs (WordPress, Drupal, etc.) are adding APIs on top of what they already have so users have the option to use traditional or decoupled. But headless CMSs typically use APIs exclusively to deliver content, there is no traditional/coupled option.
I hope this answers your question? :)
Yep, certainly does, thanks! 👍