AEM-APIs für die Bereitstellung und Verwaltung strukturierter Inhalte aem-apis-structured-content-delivery-and-management

Bereitstellung von AEM-Inhaltsfragmenten mit OpenAPI

• Diese API erstellt JSON-Antworten für die Bereitstellung strukturierter Inhalte aus Inhaltsfragmenten in AEM.
• Sie verwendet einen Pfad zu einem Inhaltsfragment als Endpunkt.
• Diese API basiert auf REST.
• Sie ist für die Bereitstellung von Inhalten optimiert, einschließlich der CDN-Integration.

AEM-GraphQL-API für die Bereitstellung von Inhaltsfragmenten

• Diese API ist schemabasiert. API-Schemata werden durch Inhaltsfragmentmodelle dargestellt, die die Inhaltsstruktur definieren.
• Diese API basiert auf GraphQL.

OpenAPIs für Inhaltsfragmente und Inhaltsfragmentmodelle

• Diese APIs sind für die Verwaltung strukturierter Inhalte vorgesehen.
• Die jeweiligen GET-Operatoren sind nicht für die Inhaltsbereitstellung optimiert.
• Diese API basiert auf REST.

Unterstützung von Inhaltsfragmenten im AEM Assets-HTTP-API

• Die ursprüngliche API für die JSON-Ausgabe für die Bereitstellung strukturierter Inhalte in AEM.
  • Diese API ist zwar robust und bewährt, liefert jedoch keine vollständig hydrierte JSON-Ausgabe. Verweise werden nur als Pfade ausgegeben, sodass sekundäre API-Anfragen zum Abrufen weiterer Inhalte erforderlich sind.
• Die Assets-HTTP-API kann auch zum Verwalten der Inhaltsfragmente und Inhaltsfragmentmodelle (CRUD) verwendet werden.
• Diese API basiert auf REST.
• Die Unterstützung von Inhaltsfragmenten in der Assets-HTTP-API wird in Zukunft eingestellt, da sie durch die Edge Delivery Services-JSON-REST-API ersetzt wird. Der Zeitplan steht noch nicht fest.

Einfachheit

• Entwicklerinnen und Entwickler sind (häufig) mit HTTP und REST vertraut. Gemäß dem Bericht Postman State of the APIs verwendet ein hoher Prozentsatz der Entwicklerinnen und Entwickler REST.

• Einfachheit schafft Vertrautheit. Bei REST gibt es keine organisatorischen Fragen, wem die Abfragen oder die App gehören, während diese Fragen bei GraphQL auftreten können.

• Die Vertrautheit geht (in der Regel) mit einer breiten Landschaft von Communitys und Tools einher. Dies ist kein inhärenter Nachteil von GraphQL, aber bei REST ist dies wahrscheinlich umfassender und tiefgreifender.

• Der einfachere Ansatz kann auch die Sicherheitsimplementierung erleichtern. Mit REST erfolgt die Filterung zum Ermitteln der Inhalte, die gerendert werden sollen, in der Client-App. Mit GraphQL erfolgt dies in einer schemabasierten Abfrage zwischen Client und Server.

Flexibilität

• Mit REST kann das Entwicklungs-Team GET für jede beliebige Ressource ausführen. Bei GraphQL ist es auf Ressourcen beschränkt, die in einem Schema definiert sind.

Caching

• JSON-Antworten auf REST-GET-Anfragen können grundsätzlich zwischengespeichert werden. GraphQL-POST-Anfragen können nicht zwischengespeichert werden, es sei denn, sie werden so konfiguriert, z. B. durch die Verwendung von persistierten AEM-Abfragen, die auf dem Server gespeichert und mit REST-ähnlichen GET-Anfragen angefordert werden.

Effizienz der Inhaltsbereitstellung

• Fokus

  • Mit GraphQL können Client-Anwendungen genau die Inhalte anfordern, die sie für die Darstellung benötigen – und nicht mehr. Dieser Ansatz verhindert eine Überlieferung von Inhalten mit übermäßiger Nutzlast und unnötigem Bandbreitenverbrauch.

• Einzelner Endpunkt

  • Während in REST jede API-Anfrage ein Endpunkt ist, gibt es in GraphQL nur einen gemeinsamen Endpunkt, und verschiedene Inhaltsanfragen werden als Abfragen unter Verwendung dieses gemeinsamen Endpunkts ausgedrückt.

Schnelle Prototypen

• Mit GraphQL ist dies ein einstufiger Prozess, der in der GraphQL-Abfrage zusammengefasst wird und die Erstellung von Prototypen erleichtern kann. REST dagegen ist ein zweistufiger Prozess:

  1. Abrufen von Inhalten mit der API.
  2. In der JSON-Antwort wird festgelegt, was für die Darstellung in der Client-App verwendet werden soll.