AEM-API:er för leverans och hantering av strukturerat innehåll aem-apis-structured-content-delivery-and-management

AEM REST OpenAPI för leverans av innehållsfragment

• Detta API skapar JSON-svar för att leverera strukturerat innehåll från innehållsfragment i AEM.
• En bana till ett innehållsfragment används som slutpunkt.
• Detta API är REST-baserat.
• Det är optimerat för innehållsleverans, inklusive CDN-integrering.

AEM GraphQL API for Content Fragment delivery

• Detta API är schemabaserat. API-scheman representeras av Content Fragment Models, som definierar innehållsstrukturen.
• Detta API är GraphQL-baserat.

Content Fragments och Content Fragment Models OpenAPIs

• Dessa API:er är avsedda för strukturerad innehållshantering.
• GET-operatorer är inte optimerade för innehållsleverans.
• Detta API är REST-baserat.

Stöd för innehållsfragment i AEM Assets HTTP API

• Ursprungligt API för JSON-utdata för strukturerad innehållsleverans i AEM.
  • Även om det är robust och bevisat levererar detta API inte fullständigt hydrerade JSON-utdata. Referenser genereras bara som sökvägar, vilket kräver sekundära API-begäranden för att hämta ytterligare innehåll.
• Assets HTTP API kan också användas för att hantera innehållsfragment och modeller för innehållsfragment (CRUD).
• Detta API är REST-baserat.
• Stöd för innehållsfragment i Assets HTTP API kommer att bli inaktuellt i framtiden eftersom det genomförs av Edge Delivery Servicens JSON REST API. Tidsskalan har inte fastställts än.

Enkelt

• Utvecklare är (ofta) bekanta med HTTP och REST. Enligt Postman State of the APIs report använder en hög andel utvecklare REST.

• Med enkelhet kommer kännedomen. Med REST finns det inga organisatoriska frågor om vem som äger frågorna och vem som äger appen, medan dessa frågor kan uppstå med GraphQL.

• Med välbekant (vanligtvis) får du tillgång till ett brett användarforum och en bred verktygslandskap. Inte en inneboende nackdel för GraphQL, utan sannolikt en bredare och djupare REST.

• Den enklare metoden kan också göra säkerhetsimplementeringen enklare. Med REST sker filtreringen för att avgöra vilket innehåll som ska återges i klientprogrammet. Med GraphQL sker detta i en schemabaserad fråga mellan klient och server.

Flexibilitet

• Med REST kan utvecklaren GET alla resurser. Med GraphQL begränsas de till resurser som definierats i ett schema.

Cachning

• JSON-svar på REST GET-begäranden är i sig tillgängliga. GraphQL POST-begäranden är inte tillgängliga om de inte görs, till exempel genom att använda AEM beständiga frågor som är lagrade på servern och begärda med REST-liknande GET-begäranden.

Effektiv leverans av innehåll

• Fokus

  • Med GraphQL kan klientapplikationer begära exakt det innehåll de behöver för återgivning - och inte längre. Den här metoden förhindrar överleverans av innehåll, med överbelastad innehållsladdning och onödig bandbreddskonsumtion.

• Enskild slutpunkt

  • I REST är varje API-begäran en slutpunkt, men i GraphQL finns det bara en gemensam slutpunkt, och olika innehållsförfrågningar uttrycks som frågor med den gemensamma slutpunkten.

Snabba prototyper

• Med GraphQL är detta en enstegsprocess som sammanförts i GraphQL-frågan och som kan underlätta framtagning av prototyper. REST å andra sidan är en tvåstegsprocess:

  1. Hämta innehåll med API.
  2. I JSON-svaret avgör du vad som ska användas för återgivning i klientprogrammet.