AEM API's voor gestructureerde levering en beheer van inhoud aem-apis-structured-content-delivery-and-management

AEM Content Fragment Delivery with OpenAPI

• Deze API maakt JSON-reacties voor het leveren van gestructureerde inhoud van Content Fragments in AEM.
• Er wordt een pad naar een inhoudsfragment gebruikt als eindpunt.
• Deze API is gebaseerd op REST.
• Deze is geoptimaliseerd voor de levering van inhoud, inclusief CDN-integratie.

AEM GraphQL API voor levering van inhoudsfragmenten

• Deze API is gebaseerd op een schema. API-schema's worden vertegenwoordigd door Content Fragment Models, die de inhoudsstructuur definiëren.
• Deze API is gebaseerd op GraphQL.

Content Fragments and Content Fragment Models OpenAPIs

• Deze API's zijn bedoeld voor gestructureerd inhoudsbeheer.
• De respectievelijke GET-operatoren zijn niet geoptimaliseerd voor de levering van inhoud.
• Deze API is gebaseerd op REST.

Eenvoud

• Ontwikkelaars zijn (vaak) vertrouwd met HTTP en REST. Volgens de Staat van Postman van het APIs- rapport, gebruikt een hoog percentage ontwikkelaars REST.

• Met eenvoud komt vertrouwdheid. Met REST zijn er geen organisatorische vragen over wie de query's bezit en wie de app bezit, terwijl deze vragen bij GraphQL kunnen rijzen.

• Met (typisch) vertrouwdheid komt een brede gemeenschap en toolend landschap. Geen inherent nadeel van GraphQL, maar waarschijnlijk breder en dieper voor REST.

• De eenvoudigere benadering kan de veiligheidsimplementatie ook vergemakkelijken. Met REST gebeurt het filteren om te bepalen welke inhoud moet worden gerenderd in de client-app. Met GraphQL gebeurt dit in een op schema gebaseerde query tussen client en server.

Flexibiliteit

• Met REST kan de ontwikkelaar GET elke bron. Met GraphQL zijn ze beperkt tot resources die binnen een schema zijn gedefinieerd.

Caching

• JSON-reacties op REST GET -verzoeken kunnen van nature in cache worden geplaatst. GraphQL POST verzoeken zijn niet cacheable, tenzij zij worden gemaakt; bijvoorbeeld, door AEM te gebruiken Persisted Vragen die op de server worden opgeslagen en met REST-als GET verzoeken worden gevraagd.

Efficiëntie van de levering van inhoud

• Focus

  • Met GraphQL-clienttoepassingen kunnen ze exact de inhoud aanvragen die ze nodig hebben voor rendering, en niet meer. Deze benadering voorkomt overlevering van inhoud, met bovenmatige opslagkosten van inhoud en onnodig bandbreedteverbruik.

• Enkel eindpunt

  • Terwijl in REST is elk API verzoek een eindpunt, in GraphQL is er slechts één gemeenschappelijk eindpunt, en de verschillende inhoudsverzoeken worden uitgedrukt als vragen gebruikend dat gemeenschappelijke eindpunt.

Snelle prototypen

• Met GraphQL is dit een proces in één stap, samengebracht in de GraphQL query, en kan het maken van prototypen eenvoudiger maken. REST daarentegen is een proces in twee stappen:

  1. Inhoud ophalen met API.
  2. In het JSON-antwoord bepaalt u wat u wilt gebruiken voor rendering in de client-app.