AEM API:er
AEM API:er innehåller abstraktioner och funktioner som är specifika för produktioner.
AEM-API:erna PageManager och Page innehåller till exempel abstraktioner för cq:Page
noder i AEM som representerar webbsidor.
Dessa noder är tillgängliga via Sling API:er som resurser och JCR-API:er som noder, men AEM API:er innehåller abstraktioner för vanliga användningsområden. Med AEM API:er säkerställs ett konsekvent beteende mellan AEM och AEM samt anpassningar och tillägg.
com.adobe.* vs com.day.* API:er
AEM-API:er har en paketspecifik inställning som identifieras av följande Java™-paket, i prioritetsordning:
com.adobe.cq
com.adobe.granite
com.day.cq
Paketet com.adobe.cq
har stöd för produktanvändningsfall, medan com.adobe.granite
har stöd för flerproduktsplattformsanvändning, som arbetsflöde eller uppgifter (som används för olika produkter: AEM Assets, Sites, osv.).
Paketet com.day.cq
innehåller ursprungliga API:er. Dessa API:er åtgärdar viktiga abstraktioner och funktioner som fanns före och/eller runt Adobe förvärv av Day CQ. Dessa API:er stöds och bör undvikas, såvida inte com.adobe.cq
- eller com.adobe.granite
-paketen inte har ett (nyare) alternativ.
Nya abstraktioner som Content Fragments och Experience Fragments är inbyggda i com.adobe.cq
-utrymmet i stället för com.day.cq
som beskrivs nedan.
Fråga API:er
AEM stöder flera frågespråk. De tre huvudspråken är JCR-SQL2, XPath och AEM Query Builder.
Det viktigaste problemet är att ha ett konsekvent frågespråk i hela kodbasen, vilket minskar komplexiteten och gör att du lättare kan förstå kostnaderna.
Alla frågespråk har i princip samma prestandaprofiler, eftersom Apache Oak kopplar dem till JCR-SQL2 för slutlig frågekörning, och konverteringstiden till JCR-SQL2 är försumbar jämfört med själva frågetiden.
Det önskade API:t är AEM Query Builder, som är den högsta nivån för abstraktion och som tillhandahåller ett robust API för att skapa, köra och hämta resultat för frågor, och som ger följande:
-
Enkel, parametriserad frågekonstruktion (frågeparametrar som modelleras som en karta)
-
Inbyggt Java™ API och HTTP API:er
-
AEM förutsäger som stöder gemensamma frågekrav
-
Utbyggbart API, som möjliggör utveckling av anpassade frågepredikat
-
JCR-SQL2 och XPath kan köras direkt via Sling och JCR API:er, vilket returnerar resultatet Sling Resources respektive JCR Nodes.
Sling API:er
Apache Sling är det RESTful-webbramverk som stöder AEM. Sling tillhandahåller routning av HTTP-begäran, modeller av JCR-noder som resurser, ger säkerhetskontext och mycket annat.
Sling API:er har dessutom fördelen att skapas för tillägg, vilket innebär att det ofta är enklare och säkrare att förstärka beteendet för program som skapats med Sling API:er än de mindre utökningsbara JCR-API:erna.
Vanliga användningsområden för Sling API:er
-
Åtkomst till JCR-noder som Sling Resources och åtkomst till deras data via ValueMaps.
-
Tillhandahåller säkerhetskontext via ResourceResolver.
-
Skapar och tar bort resurser via ResourceResolver create/move/copy/delete-metoder.
-
Uppdaterar egenskaper via ModiitableValueMap.
-
Byggstenar för bearbetning av begäranden
-
Byggstenar för asynkron bearbetning
JCR-API:er
JCR-API:erna (Java™ Content Repository) 2.0 är en del av en specifikation för JCR-implementeringar (för AEM Apache Jackrabbit Oak). All JCR-implementering måste följa och implementera dessa API:er, och är därför den lägsta nivån för API för interaktion med AEM-innehåll.
Själva JCR är ett hierarkiskt/trädbaserat NoSQL-datalager som AEM använder som innehållsdatabas. JCR har en mängd API:er som stöds, från innehålls-CRUD till frågor om innehåll. Trots detta robusta API är det sällsynt att de föredras framför AEM- och Sling-abstraktioner på högre nivå.
Använd alltid JCR-API:erna framför API:erna i Apache Jackrabbit Oak. JCR-API:erna är till för interaktion med en JCR-databas, medan Oak-API:erna är till för implementering av en JCR-databas.