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

AEM REST OpenAPI voor levering van inhoudsfragmenten

• 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.

GraphQL API AEM 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.

Ondersteuning voor inhoudsfragmenten in de AEM Assets HTTP API

• De oorspronkelijke API voor de JSON-uitvoer voor gestructureerde inhoudslevering in AEM.
  • Terwijl robuust en bewezen, levert dit API volledig gehydrateerde output JSON niet. Verwijzingen worden alleen uitgevoerd als paden, waarvoor secundaire API-aanvragen nodig zijn om verdere inhoud op te halen.
• De Assets HTTP-API kan ook worden gebruikt voor het beheer van Content Fragments en Content Fragment Models (CRUD).
• Deze API is gebaseerd op REST.
• Ondersteuning voor inhoudsfragmenten in Assets HTTP API wordt in de toekomst vervangen, omdat dit wordt opgevolgd door de JSON REST API van de Edge Delivery Services. Het tijdschema is nog niet vastgesteld.

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 Persisted Vragen te gebruiken 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.