無頭 CMS 的好處：探索彈性與可擴充性
了解無頭 CMS 如何將內容與呈現方式分開、它能帶來哪些好處，以及團隊仍需承擔哪些責任。
想像你正在發佈一場演講。標題、照片、說明與開始時間需要同時出現在網站和手機應用程式中。時間變更時，你希望只要修正一次；同時也希望網站看起來像網站，應用程式則有應用程式的感覺。
無頭內容管理系統將這兩項工作分開：維持資訊有條理，以及決定讀者如何看見這些資訊。這種分離可能很有用，但好處取決於你要發佈什麼，以及誰會建置和維護這些連接。
「無頭」到底是什麼意思？
CMS 是編輯人員撰寫、整理與發佈內容的地方。在傳統設定中，它也會提供將內容轉換成網頁的範本。無頭 CMS 則把呈現方式交給獨立的網站、應用程式或其他介面。
兩端透過 API 溝通。API 是一套約定好的方式，讓一個軟體向另一個軟體請求資訊。網站可以要求演講的標題、時間與照片，然後把它們放進自己的版面；應用程式也能要求相同資訊，再以不同方式排列。
Strapi 就是一個例子。它提供編輯介面、內容模型，以及供應用程式使用的 API。API 讓開發者能夠存取內容，但不會替他們設計讀者體驗。
彈性在哪裡變得有用
一份內容可以服務多個地方。 演講時間可以放在單一欄位中，不必複製到多個各自維護的頁面。每個應用程式仍需要可運作的連接，以及取得更新內容的方法。舊的快取頁面在重新整理前，可能會一直保持過時。
新設計不必代表重寫每一篇文章。 如果標題、段落、圖片與圖說獨立於特定頁面版面儲存，新的前端就能重新使用它們。當內容模型清楚描述素材，而不是把它存成一大段依賴特定版面的標記時，這種方式最有效。
不同讀者可以看到不同的呈現方式。 手機螢幕、長篇文章和活動展示畫面有不同需求。同一份底層資訊可以支援這三者，不必把它們全部塞進同一個範本。
這種架構不會替你完成哪些事
無頭不代表自動變快。頁面可以預先準備並快速提供，也可能在任何內容出現前先發出一連串緩慢請求。圖片、快取、託管，以及前端的建置方式，仍然會影響結果。將部分分開後，團隊可以選擇在哪裡改善效能與增加容量，但仍有人需要做出選擇並加以測試。
編輯人員需要的不只是一個輸入框。他們還需要預覽草稿、檢查連結與圖片、以正確語言發佈，以及復原先前的版本。開發者必須把這些工作連接到新的前端。架構圖中看起來優雅的系統，仍然可能讓日常發佈變得不方便。
同樣的區分也適用於控制權。API 不會決定誰能改變規則、你是否能匯出所有內容，或供應商停止服務時你是否仍能繼續發佈。這些問題取決於軟體、託管安排、權限，以及轉移到另一個系統的實際途徑。
試做一項完整的發佈工作
- 選擇一項具代表性的內容，例如包含照片、日期、說明與第二種語言的演講。
- 請負責編輯的人建立草稿，並預覽網站與應用程式的實際版面。
- 發佈內容、修改時間，並確認每個目的地何時顯示修正後的內容。
- 還原先前的版本。匯出內容與媒體，接著確認若要在其他地方使用它們，還需要哪些工作。
這項小型測試揭示的事情，比功能清單更多。它會顯示這種架構是否給團隊實用的自由，以及日常工作是否容易管理。
因應發佈需求選擇它
當多個應用程式需要相同的結構化內容，或讀者體驗需要大量客製化開發時，無頭 CMS 可能非常適合。如果是只有一個發佈目的地的簡單網站，結合編輯與呈現方式的系統可能需要較少工作。先從工作本身出發，再選擇架構。
如要進行更廣泛的比較，請閱讀如何根據發佈工作量與內容搬遷能力選擇 CMS。