Version | Artikellänk |
---|---|
AEM 6.5 | Klicka här |
AEM as a Cloud Service | Den här artikeln |
Läs mer om stöd för innehållsfragment i Assets HTTP API, en viktig del av Adobe Experience Manager (AEM) headless delivery feature.
The Resurser för HTTP API Innefattar:
Den aktuella implementeringen av Assets HTTP API baseras på REST arkitekturstil.
The Resurser REST API ger utvecklare av Adobe Experience Manager as a Cloud Service tillgång till innehåll (som lagras i AEM) direkt via HTTP-API:t via CRUD-åtgärder (Create, Read, Update, Delete).
Med API kan du använda Adobe Experience Manager as a Cloud Service som headless CMS (Content Management System) genom att tillhandahålla Content Services till ett JavaScript-klientprogram. Eller något annat program som kan köra HTTP-begäranden och hantera JSON-svar.
Till exempel: Single Page Applications (SPA), ramverksbaserade eller anpassade, kräver innehåll som tillhandahålls via HTTP API, ofta i JSON-format.
while AEM kärnkomponenter tillhandahåller ett anpassningsbart API som kan hantera nödvändiga läsåtgärder för detta ändamål, och vars JSON-utdata kan anpassas, kräver de AEM WCM-kunskaper (Web Content Management) för implementering. Detta beror på att de måste finnas på sidor som är baserade på dedikerade AEM. Det är inte varje SPA utvecklingsorganisation som har direkt tillgång till sådan kunskap.
Detta är när REST API:t för resurser kan användas. Med det kan utvecklare komma åt resurser (till exempel bilder och innehållsfragment) direkt, utan att först behöva bädda in dem på en sida, och leverera innehållet i serialiserat JSON-format.
Det går inte att anpassa JSON-utdata från Assets REST API.
Med Assets REST API kan utvecklare ändra innehåll genom att skapa nya, uppdatera eller ta bort befintliga resurser, innehållsfragment och mappar.
Resursens REST API:
följer HATEOAS-principen
implementerar SIREN-format
Resursens REST API är tillgängligt för varje körklar installation av en nyligen använd Adobe Experience Manager as a Cloud Service-version.
Resurser REST API erbjuder REST-liknande åtkomst till resurser som lagras i en AEM.
Den använder /api/assets
slutpunkten och kräver att sökvägen till resursen har åtkomst till den (utan radavståndet) /content/dam
).
/content/dam/path/to/asset
/api/assets/path/to/asset
Till exempel för att komma åt /content/dam/wknd/en/adventures/cycling-tuscany
, begäran /api/assets/wknd/en/adventures/cycling-tuscany.json
Åtkomst över:
/api/assets
inte behöver du använda .model
väljare./content/path/to/page
gör kräver att .model
väljare.HTTP-metoden avgör vilken åtgärd som ska utföras:
Parametrarna för begärandeinnehåll och/eller URL kan användas för att konfigurera vissa av dessa åtgärder. Du kan till exempel definiera att en mapp eller en resurs ska skapas av en POST begäran.
Det exakta formatet för begäranden som stöds definieras i API-referens dokumentation.
Alla förfrågningar är atomiska.
Detta innebär att följande (write
) kan inte kombineras till en enda transaktion som kan lyckas eller misslyckas som en enskild enhet.
Proportioner | Resurser REST API |
AEM (komponenter med Sling Models) |
Användningsfall som stöds | Allmänt syfte. | Optimerad för konsumtion i ett Single Page-program (SPA) eller i något annat (innehållsförbrukande) sammanhang. Den kan också innehålla layoutinformation. |
Åtgärder som stöds | Skapa, läsa, uppdatera, ta bort. Med ytterligare åtgärder, beroende på enhetstyp. |
Skrivskyddad. |
Åtkomst | Den kan nås direkt. Använder En exempelsökväg skulle se ut så här: |
Det måste refereras via en AEM på en AEM. Använder En exempelsökväg skulle se ut så här: |
Dokumentskydd | Flera alternativ är möjliga. OAuth föreslås; kan konfigureras separat från standardinställningen. |
Använder AEM standardinställningar. |
Arkitektur | Skrivåtkomst adresserar vanligtvis en Author-instans. Läsningen kan även dirigeras till en Publish-instans. |
Eftersom den här metoden är skrivskyddad används den vanligtvis för publiceringsinstanser. |
Utdata | JSON-baserade SIREN-utdata: utförlig, men kraftfull. Det gör det möjligt att navigera i innehållet. | JSON-baserade egna utdata som kan konfigureras via Sling-modeller. Att navigera i innehållsstrukturen är svårt att implementera (men inte nödvändigtvis omöjligt). |
Om REST API:t för Resurser används i en miljö utan särskilda autentiseringskrav måste AEM CORS-filtret konfigureras korrekt.
Mer information finns i:
I miljöer med specifika autentiseringskrav rekommenderas OAuth.
Innehållsfragment är en specifik typ av resurs, se Arbeta med innehållsfragment.
Mer information om funktioner som är tillgängliga via API finns i:
Resursens REST API stöder sidindelning (för GET-begäranden) via URL-parametrarna:
offset
- numret på den första (underordnade) entiteten som ska hämtaslimit
- det maximala antalet returnerade enheterSvaret innehåller sidindelningsinformation som en del av properties
i SIREN-utdata. Detta srn:paging
egenskapen innehåller det totala antalet (underordnade) entiteter ( total
), förskjutningen och gränsen ( offset
, limit
) enligt begäran.
Sidindelning används vanligtvis för behållarentiteter (d.v.s. mappar eller resurser med återgivningar), eftersom den relaterar till den begärda entitetens underordnade.
GET /api/assets.json?offset=2&limit=3
...
"properties": {
...
"srn:paging": {
"total": 7,
"offset": 2,
"limit": 3
}
...
}
...
Mappar fungerar som behållare för resurser och andra mappar. De återspeglar strukturen i AEM innehållsdatabas.
Resursens REST API visar åtkomst till egenskaperna för en mapp. Till exempel dess namn och titel. Resurser visas som underordnade enheter till mappar och undermappar.
Beroende på resurstypen för de underordnade resurserna och mapparna kan listan med underordnade enheter redan innehålla den fullständiga uppsättningen egenskaper som definierar respektive underordnade enhet. Alternativt kan bara en reducerad uppsättning egenskaper visas för en enhet i den här listan över underordnade enheter.
Om en resurs begärs returnerar svaret dess metadata, t.ex. titel, namn och annan information som definieras i respektive resursschema.
Den binära informationen för en resurs visas som en SIREN-länk av typen content
.
Resurser kan ha flera renderingar. Dessa visas vanligtvis som underordnade enheter, och ett undantag är en miniatyrrendering, som visas som en länk av typen thumbnail
( rel="thumbnail"
).
A innehållsfragment är en särskild typ av tillgång. De kan användas för att komma åt strukturerade data, t.ex. texter, siffror och datum.
Som det finns flera skillnader mellan standard resurser (t.ex. bilder eller ljud), kan vissa andra regler gälla för att hantera dem.
Innehållsfragment:
Visa inga binära data.
Finns i JSON-utdata (i properties
egenskap).
De betraktas också som atomiska. Det innebär att elementen och variationerna visas som en del av fragmentets egenskaper jämfört med som länkar eller underordnade enheter. Detta ger effektiv åtkomst till nyttolasten för ett fragment.
För närvarande visas inte modellerna som definierar strukturen för ett innehållsfragment via ett HTTP-API. Därför är konsument måste känna till modellen för ett fragment (minst ett minimum), även om den mesta informationen kan härledas från nyttolasten, eftersom datatyper och så vidare är en del av definitionen.
Om du vill skapa ett innehållsfragment måste modellens (interna databas) sökväg anges.
Associerat innehåll visas inte.
Användningen kan variera beroende på om du använder en AEM författar- eller publiceringsmiljö, tillsammans med ditt specifika användningsexempel.
Vi rekommenderar att skapandet binds till en Author-instans (och det finns för närvarande inget sätt att replikera ett fragment som ska publiceras med detta API).
Leverans är möjlig från båda, eftersom AEM endast skickar begärt innehåll i JSON-format.
Lagring och leverans från en AEM Author-instans bör räcka för program bakom brandväggen, mediabibliotek.
För live-webbleverans rekommenderas en AEM Publish-instans.
Dispatcher-konfigurationen på AEM molninstanser kan blockera åtkomst till /api
.
Se API-referens. Särskilt gäller följande: Adobe Experience Manager Assets API - innehållsfragment.
Det finns några begränsningar:
Följande statuskoder kan ses under de relevanta omständigheterna:
200 (OK)
Returneras när:
GET
PUT
201 (Skapad)
Returneras när:
POST
404 (Hittades inte)
Returneras när:
500 (Internt serverfel)
Detta fel returneras:
I följande exempel visas vanliga scenarier när den här felstatusen returneras, tillsammans med felmeddelandet (monospace) som genereras:
Överordnad mapp finns inte (när ett innehållsfragment skapas via POST
)
Ingen innehållsfragmentmodell har angetts (cq:model saknas), kan inte läsas (på grund av en ogiltig sökväg eller ett behörighetsproblem) eller så finns det ingen giltig fragmentmodell:
No content fragment model specified
Cannot create a resource of given model '/foo/bar/qux'
Det gick inte att skapa innehållsfragmentet (eventuellt ett behörighetsproblem):
Could not create content fragment
Titeln och/eller beskrivningen kunde inte uppdateras:
Could not set value on content fragment
Det gick inte att ange metadata:
Could not set metadata on content fragment
Innehållselementet kunde inte hittas eller kunde inte uppdateras
Could not update content element
Could not update fragment data of element
De detaljerade felmeddelandena returneras på följande sätt:
{
"class": "core/response",
"properties": {
"path": "/api/assets/foo/bar/qux",
"location": "/api/assets/foo/bar/qux.json",
"parentLocation": "/api/assets/foo/bar.json",
"status.code": 500,
"status.message": "...{error message}.."
}
}
Här finns detaljerade API-referenser:
Mer information finns i: