API AEM pour la diffusion et la gestion de contenu structurées aem-apis-structured-content-delivery-and-management

AEM REST OpenAPI pour la diffusion de fragments de contenu

• Cette API crée des réponses JSON pour la diffusion de contenu structuré à partir de fragments de contenu dans AEM.
• Il utilise un chemin d’accès à un fragment de contenu comme point de terminaison.
• Cette API est basée sur REST.
• Il est optimisé pour la diffusion de contenu, y compris l’intégration CDN.

API GraphQL AEM pour la diffusion de fragments de contenu

• Cette API est basée sur des schémas. Les schémas d’API sont représentés par des modèles de fragment de contenu, qui définissent la structure de contenu.
• Cette API est basée sur GraphQL.

API ouvertes de fragments de contenu et de modèles de fragments de contenu

• Ces API sont destinées à la gestion de contenu structuré.
• Les opérateurs de GET respectifs ne sont pas optimisés pour la diffusion de contenu.
• Cette API est basée sur REST.

Prise en charge des fragments de contenu dans l’API HTTP AEM Assets

• API d’origine pour la sortie JSON pour la diffusion de contenu structuré dans AEM.
  • Bien qu’elle soit robuste et prouvée, cette API ne fournit pas de sortie JSON entièrement hydratée. Les références ne sont générées que sous forme de chemins d’accès, ce qui nécessite des requêtes d’API secondaires pour récupérer du contenu supplémentaire.
• L’API HTTP Assets peut également être utilisée pour gérer les fragments de contenu et les modèles de fragments de contenu (CRUD).
• Cette API est basée sur REST.
• La prise en charge des fragments de contenu dans l’API HTTP Assets sera abandonnée à l’avenir, car elle sera remplacée par l’API REST JSON Edge Delivery Services. Le calendrier n'a pas encore été fixé.

Simplicité

• Les développeurs sont (souvent) familiarisés avec HTTP et REST. Selon le rapport Postman State of the APIs, un pourcentage élevé de développeurs utilisent REST.

• Avec la simplicité vient la familiarité. Avec REST, il n’existe aucune question d’organisation concernant le propriétaire des requêtes et le propriétaire de l’application, alors que ces questions peuvent se poser avec GraphQL.

• La familiarité (typiquement) s’accompagne d’une vaste communauté et d’un vaste paysage d’outils. Pas un inconvénient inhérent à GraphQL, mais susceptible d’être plus large et plus profond pour REST.

• L’approche plus simple peut également faciliter la mise en oeuvre de la sécurité. Avec REST, le filtrage permettant de déterminer le contenu dont le rendu doit être effectué s’effectue dans l’application cliente. Avec GraphQL, cela se produit dans une requête basée sur un schéma entre le client et le serveur.

Flexibilité

• Avec REST, le développeur peut GET n’importe quelle ressource. Avec GraphQL, elles sont limitées aux ressources définies dans un schéma.

Mise en cache

• Les réponses JSON aux requêtes REST GET peuvent par nature être mises en cache. Les requêtes GraphQL POST ne peuvent pas être mises en cache, sauf si elles le sont ; par exemple, en utilisant AEM requêtes persistantes stockées sur le serveur et demandées avec des requêtes de type REST GET.

Efficacité de la diffusion de contenu

• Cible d’action

  • Avec GraphQL, les applications clientes peuvent demander le contenu exact dont elles ont besoin pour le rendu - et pas plus. Cette approche empêche la sur-diffusion du contenu, avec des charges de contenu excessives et une consommation de bande passante inutile.

• Point d’entrée unique

  • Bien que dans REST, chaque requête d’API soit un point de terminaison, dans GraphQL, il n’y a qu’un seul point de terminaison commun et les différentes requêtes de contenu sont exprimées sous la forme de requêtes utilisant ce point de terminaison commun.

Prototypage rapide

• Avec GraphQL, il s’agit d’un processus à une étape, rassemblé dans la requête GraphQL, qui peut faciliter le prototypage. REST, en revanche, est un processus en 2 étapes :

  1. Récupérez du contenu avec l’API.
  2. Dans la réponse JSON, déterminez les éléments à utiliser pour le rendu dans l’application cliente.