用於傳遞和管理結構化內容的 AEM API aem-apis-structured-content-delivery-and-management

透過 OpenAPI 傳遞 AEM 內容片段

• 此 API 建立 JSON 回應，用於在 AEM 中傳遞來自內容片段的結構化內容。
• 其使用內容片段的路徑做為端點。
• 此 API 以 REST 為基礎。
• 其針對內容傳遞包括 CDN 整合進行最佳化。

用於傳遞內容片段的 AEM GraphQL API

• 此 API 以結構描述為基礎。API 結構描述由內容片段模型呈現，其會定義內容結構。
• 此 API 以 GraphQL 為基礎。

內容片段和內容片段模型的 OpenAPI

• 這些 API 是用來管理結構化內容。
• 各 GET 運算子並未針對內容傳遞進行最佳化。
• 此 API 以 REST 為基礎。

簡單性

• 開發人員通常（會）熟悉HTTP和REST。 根據API報告🔗的Postman狀態，有高比例的開發人員使用REST。

• 透過簡單而熟悉。 使用REST時，不會出現關於誰擁有查詢以及誰擁有應用程式的組織問題，而GraphQL則可能出現這些問題。

• 熟悉度（通常是）帶來廣泛的社群和工具環境。 這不是GraphQL固有的缺點，但對於REST而言可能會更廣闊、更深層。

• 更簡單的方法也可以讓安全性實作更容易。 使用REST時，用於決定要呈現所有內容在使用者端應用程式中進行的篩選。 透過GraphQL，這會發生在使用者端與伺服器之間的結構描述型查詢中。

彈性

• 透過REST，開發人員可以GET任何資源。 使用GraphQL時，這些資源會限制在結構描述中定義的資源。

快取

• REST GET要求的JSON回應本身可快取。 無法快取GraphQL POST要求，除非進行快取；例如，使用儲存在伺服器上，並且以類似REST的GET要求要求的AEM持續查詢。

內容傳遞效率

• 焦點

  • 透過GraphQL使用者端應用程式，可請求轉譯所需的確切內容，而且不再需要。 此方法可以防止內容過度傳送、內容負載過多以及不必要的頻寬消耗。

• 單一端點

  • 在REST中，每個API要求都是端點，但在GraphQL中，只有一個通用端點，而不同的內容要求會使用該通用端點以查詢形式表示。

快速原型製作

• 透過GraphQL，只需一步驟就能在GraphQL查詢中將其整合，讓建立原型更加容易。 另一方面，REST是兩步驟流程：

  1. 使用API擷取內容。
  2. 在JSON回應中，決定要在使用者端應用程式中呈現的內容。