Headless CMS – Open Source, schnell & effizient

Ohne Content-Ma­nage­ment-Systeme wäre die Arbeit von Content-Er­stel­lern um einiges kom­pli­zier­ter. Statt direkt in den Code der Website werden bei einem CMS die Inhalte über ein Backend ein­ge­pflegt und vom System im Frontend aus­ge­ge­ben. Dies funk­tio­niert sehr gut, solange man nur eine einzelne Website verwaltet. In­zwi­schen bespielen Re­dak­teu­re und Content-Manager aber häufig mehrere Sites und Ap­pli­ka­tio­nen gleich­zei­tig. Dazu benötigt man wiederum mehrere CMS, was u. U. bedeutet, dass Inhalte händisch von einem zum anderen über­tra­gen werden müssen. Oder man setzt auf ein Headless CMS, das die Ausgabe in beliebig viele Medien er­mög­licht.

Ein Headless CMS ist sowohl eine Wei­ter­ent­wick­lung als auch eine Ver­knap­pung eines klas­si­schen CMS. Dem System werden integrale Be­stand­tei­le genommen, um es für un­ter­schied­lichs­te Ausgaben kom­pa­ti­bel zu machen. Das gelingt dadurch, dass Frontend und Backend in einem Headless CMS nicht mehr mo­no­li­thisch mit­ein­an­der verknüpft sind. Das fehlende Frontend ist auch der Grund, wieso derartige CMS-Systeme als „kopflos“ (englisch: „headless“) be­zeich­net werden.

Die Ent­kopp­lung von Front- und Backend führt dazu, dass Headless-CMS her­vor­ra­gend zum Jamstack passt. Mit Jamstack werden Soft­ware­lö­sun­gen be­zeich­net, die vorrangig auf der Pro­gram­mier­spra­che Ja­va­Script beruhen und deren Ziel es ist, die An­wen­dungs­lo­gik einer Website cli­ent­sei­tig be­reit­zu­stel­len. Die für Websites er­for­der­li­chen Inhalte werden beim Jamstack über Pro­gram­mier­schnitt­stel­len ab­ge­wi­ckelt. Solche Schnitt­stel­len stellt ein Headless CMS bereit.

Headless CMS bekommen immer mehr Auf­merk­sam­keit. Der Grund: Inhalte werden zunehmend nicht nur im Web ver­öf­fent­licht, sondern auch über mobile Apps aus­ge­spielt. Um doppelte Arbeit zu vermeiden, greift man zu Headless-Content-Ma­nage­ment-Systemen. Die leicht­ge­wich­ti­gen Systeme können Inhalte auf ver­schie­de­nen Kanäle aus­spie­len Das Konzept geht von ein­fachs­ten Methoden aus, die vielfach kom­pa­ti­bel sind – und passt so perfekt zum Headless CMS.

Um die Ver­wen­dung dieser Systeme möglichst einfach zu gestalten, setzt man auf eine mo­no­li­thi­sche Ver­knüp­fung von Frontend und Backend. Auf der Ad­mi­nis­tra­ti­ons­ober­flä­che von WordPress z. B. kann man auch ohne um­fas­sen­de Webdesign-Kennt­nis­se mithilfe der Template-Engine das Aussehen der Website verändern. Das bedeutet aber auch, dass man bei der Er­stel­lung an die Vorgaben des Systems gebunden ist. Das gilt sowohl für die Anzahl der Ausgaben als auch für die Ver­wen­dung der Pro­gram­mier­spra­che (bei WordPress ist das PHP). Um dieses Korsett zu umgehen, kann man zu einem Headless CMS wechseln.

Bei einem REST-API (Re­pre­sen­ta­tio­nal State Transfer-Ap­pli­ca­ti­on Pro­gramming Interface) handelt es sich um eine Schnitt­stel­le, die wenig komplex, aber sehr flexibel ein­setz­bar ist. Ein REST-API verwendet die de­fi­nier­ten HTTP-An­fra­ge­me­tho­den wie PUT, GET, POST und DELETE zur Kom­mu­ni­ka­ti­on. Mit solchen Befehlen kann ein Client auf die In­for­ma­tio­nen des Servers zugreifen, diese abrufen oder gar verändern. REST folgt also prin­zi­pi­ell dem Ar­chi­tek­tur­stil des Webs. REST-APIs (oft auch „RESTful APIs“ genannt) sind nach diesen Kriterien aufgebaut:

• Server stellen Res­sour­cen zur Verfügung: Ein REST-API steht über einen Server auch externen An­wen­dun­gen zur Verfügung. Der Zugang funk­tio­niert dem­zu­fol­ge nicht nur lokal.

• Adressen iden­ti­fi­zie­ren Dinge: Un­ter­schied­li­che An­wen­dungs­ar­ten benötigen un­ter­schied­li­che Da­tei­for­ma­te. Die URI/URL referiert bei REST aber nicht auf eine Ressource in einem be­stimm­ten Format, sondern nur auf das Element an sich. Per Content Nego­tia­ti­on fordern die Clients das Element im ge­wünsch­ten Format an.

• Nach­rich­ten sind selbst­er­klä­rend: Jede Nachricht an den Server ist in sich ab­ge­schlos­sen und referiert nicht auf eine vor­her­ge­hen­de.

• Ver­knüp­fung der Res­sour­cen durch Links: Innerhalb von REST sind Objekte durch Hy­per­links mit­ein­an­der verknüpft, damit eine einfache Na­vi­ga­ti­on gegeben ist.

Durch die Ein­hal­tung dieser Ar­chi­tek­tur­prin­zi­pi­en funk­tio­niert die Kom­mu­ni­ka­ti­on zwischen Server/API und un­ter­schied­li­chen Clients pro­blem­los. Deshalb ist die REST-Ar­chi­tek­tur perfekt für ein Headless-CMS-API geeignet.

Die be­schrie­be­ne Ab­tren­nung ist von zwei Per­spek­ti­ven aus sinnvoll: Aus Sicht der Backend-Ent­wick­lung gibt es den Wunsch, Content nicht nur über eine Ausgabe zu ver­brei­ten. In einem Headless CMS ist es egal, auf was für einer Plattform der Inhalt aus­ge­ge­ben werden soll. Das REST-API stellt nur die Daten (in Form von JSON) zur Verfügung. Diese können von jedem be­lie­bi­gen Frontend gelesen werden, egal mit welchen Techniken sie pro­gram­miert sind.

Aber auch aus Sicht der Frontend-Ent­wick­lung zeigen sich Vorteile: Als Web­de­si­gner ist man bei einem Headless CMS nicht mehr an die Vor­aus­set­zun­gen des Content-Ma­nage­ments gebunden. So ist auch die Pro­gram­mier­spra­che nicht mehr vor­ge­ge­ben. Dadurch wird der Bau von mobilen Apps auf un­ter­schied­li­chen Platt­for­men möglich. Einzig die Rohdaten müssen sich empfangen und ver­ar­bei­ten lassen. Das bietet bei der Dar­stel­lung sehr viel mehr Spielraum, als es mit den meisten klas­si­schen CMS möglich ist.

Ein weiterer Vorteil ist die Fähigkeit der dy­na­mi­schen Abfrage. Die erneute Abfrage von Inhalten auf einer Website fordert bei einem klas­si­schen CMS ein Neuladen der Webpage. Das REST-API hingegen liefert dy­na­mi­sche Daten, die jederzeit in die Sei­ten­struk­tur in­te­griert werden können, auch ohne diese neu zu laden.

Durch die Trennung des Headless-CMS-Backends vom in­di­vi­du­el­len Frontend ergibt sich zudem eine prak­ti­sche Situation: Da Trends im Webdesign re­gel­mä­ßi­gen Ver­än­de­run­gen un­ter­lie­gen, ist es sinnvoll, das Frontend der eigenen Website von Zeit zu Zeit an­zu­pas­sen. Ist dieses nicht an Datenbank und Content-Ma­nage­ment gebunden, lässt es sich auch un­ab­hän­gig davon be­ar­bei­ten. Re­dak­teu­re können also weiter Inhalte ein­stel­len, verwalten und ver­öf­fent­li­chen, während an einem neuen Frontend ge­ar­bei­tet wird.

Die Vorteile eines Headless CMS in der Übersicht:

• Un­be­grenz­te Anzahl von Frontends
• Kom­bi­nier­bar mit un­ter­schied­li­chen Pro­gram­mier­spra­chen
• Fle­xi­ble­re Ge­stal­tung des Frontends
• Kon­ti­nui­tät durch Ent­kopp­lung
• Dy­na­mi­sche Daten

Anbieter von Headless-Content-Ma­nage­ment-Systemen gibt es bereits einige auf dem Markt, und es werden immer mehr. Die nach­fol­gend auf­ge­zähl­ten Her­stel­ler un­ter­schei­den sich in erster Linie darin, ob sie ein kos­ten­pflich­ti­ges Ge­samt­pa­ket (als Software-as-a-Service) oder eine freie Open-Source-Variante anbieten. Darüber hinaus stellen sie un­ter­schied­li­che Hosting-Angebote zur Verfügung.

Alle In­for­ma­tio­nen sind auf dem Stand von November 2021.

Seit Headless CMS immer häufiger dis­ku­tiert werden, ori­en­tie­ren sich auch die Anbieter tra­di­tio­nel­ler Content-Ma­nage­ment-Systeme um. WordPress z. B. hat ab der Version 4.7 die REST-API als in­te­gra­len Be­stand­teil eingefügt. In früheren Versionen konnte diese nur über ein Plug-in zu­ge­schal­tet werden. Die Er­wei­te­rung macht es aber nicht zu einem Headless CMS: WordPress wird vielmehr zu einem Decoupled CMS. Nutzer, die den Umfang der Content-Lösung inklusive Template-Engine schätzen, können auch weiterhin ohne Funk­ti­ons­ver­lus­te damit arbeiten. Wer aber das CMS bei­spiels­wei­se auch für die Ver­wal­tung der Inhalte einer App verwenden möchte, pro­fi­tiert von der ein­ge­füg­ten Schnitt­stel­le. Auch Drupal lässt sich zu einem Hybriden um­funk­tio­nie­ren, denn auch dieses Open-Source-CMS hält ab Version 8 mit den RESTful Web Services eine Mög­lich­keit bereit, um Inhalte in weiteren Frontends aus­zu­ge­ben.

Ob Sie von Ihrem an­ge­stamm­ten System zu einem Headless CMS wechseln sollten, hängt in erster Linie davon ab, was Sie planen. Wollen Sie Ihre Inhalte nur auf einer Website, etwa einem Blog, prä­sen­tie­ren, ist das Abstoßen des Frontends keine gute Idee. Zwar bieten Headless CMS auch Vorteile, die über die Menge der möglichen Aus­ga­be­me­di­en hin­aus­ge­hen, dies dürfte aber in den sel­tens­ten Fällen den Aufwand recht­fer­ti­gen. Auch die Ver­wen­dung eines Decoupled CMS hat dann keinen Mehrwert: Warum eine Schnitt­stel­le im­ple­men­tie­ren, wenn man doch nur das ein­ge­bau­te Frontend des Systems nutzt?

Anders sieht es aus, wenn Sie Ihren Content auf ver­schie­de­nen Platt­for­men prä­sen­tie­ren. Headless CMS spielen besonders dann ihre Stärken aus, wenn Sie große Projekte rea­li­sie­ren wollen. Mul­ti­ka­nal-Fä­hig­kei­ten, Websites in PHP, Python oder Ruby, Apps für iOS oder Android – alles kein Problem mehr. Re­dak­teu­re und andere Content-Ersteller können wie gewohnt ihre Inhalte über das Interface des Backends verwalten. Um die Dar­stel­lung kümmern sich bei Headless CMS (und bei richtiger Nutzung von Decoupled CMS) nun pro­fes­sio­nel­le Frontend-Ent­wick­ler – können das aber eben auch mit aller Freiheit; das REST-API macht es möglich.

Die Um-Ent­wick­lung (von einer Wei­ter­ent­wick­lung kann man bei der Hal­bie­rung eines Systems ei­gent­lich nicht sprechen) von Content-Ma­nage­ment-Systemen ist eine Reaktion auf die ver­än­der­ten An­for­de­run­gen des Internets. Die Be­son­der­hei­ten von Smart­phones, dem Internet of Things oder vir­tu­el­len Rea­li­tä­ten machen ein Umdenken beim Erstellen und Ver­öf­fent­li­chen von Content nötig. Headless und Decoupled CMS sind dabei nur die Anfänge. Daher sollte man, selbst wenn derzeit die Arbeit mit einem tra­di­tio­nel­len CMS noch voll­kom­men ausreicht, die Ent­wick­lun­gen nicht aus den Augen verlieren. In An­be­tracht der rasanten Ent­wick­lun­gen der letzten Jahre könnte es sein, dass klas­si­sche CMS bald genauso wenig den Ge­wohn­hei­ten und Be­dürf­nis­sen vieler Nutzer ent­spre­chen werden wie jetzt schon statische Websites.