REST API V2-checklista rest-api-v2-checklist

Krav

Risker

Använd ett registrerat program med omfattningen REST API v2.

Risker som utlöser HTTP 401 "Obehöriga" felsvar, överbelastar systemresurser och ökar fördröjningen.

Lagra klientens autentiseringsuppgifter i beständig lagring och återanvänd dem för varje åtkomsttokenbegäran.

Riskerar att autentiseringen går förlorad när klientens autentiseringsuppgifter genereras om.

Lagra åtkomsttokens i beständigt lagringsutrymme och återanvänd dem tills de förfaller.

Begär ingen ny token för varje REST API v2-anrop. Uppdatera bara åtkomsttoken när de upphör att gälla.

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Krav

Risker

Hämta bara konfigurationssvaret när du begär att användaren ska välja sin MVPD (TV-leverantör) före autentiseringsfasen.

Du behöver inte hämta konfigurationssvaret när:

• Användaren är redan autentiserad.
• Användaren erbjuds tillfällig åtkomst.
• Användarautentiseringen har upphört att gälla, men användaren kan uppmanas att bekräfta att han/hon fortfarande är prenumerant på den tidigare valda MVPD.

Risker överbelastar systemresurser och ökar fördröjningen.

Lagra användarens val av Pay TV-leverantör (MVPD) i beständigt lagringsutrymme och använd detta i alla efterföljande faser:

• I konfigurationssvarsarkivet har användaren valt MVPD "id".
• I konfigurationssvarsarkivet har användaren valt MVPD "displayName".
• I konfigurationssvarsarkivet har användaren valt MVPD "logoUrl".

Risker överbelastar systemresurser och ökar fördröjningen.

Krav

Risker

Starta avsökningsfunktionen under följande villkor:

Autentisering utförd i det primära (skärm) programmet

• Det primära (direktuppspelande) programmet ska starta avsökningen när användaren kommer till den sista målsidan, efter att webbläsarkomponenten har läst in den URL som angetts för parametern "redirectUrl" i Sessions-slutpunktsbegäran.

Autentisering utförd i ett sekundärt (skärm) program

• Det primära (direktuppspelande) programmet bör starta avsökningen så snart användaren initierar autentiseringsprocessen, direkt efter att ha tagit emot Sessionernas slutpunktssvar och visat autentiseringskoden för användaren.

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Stoppa avsökningsmekanismen under följande villkor:

Autentisering slutförd

• Användarens profilinformation har hämtats, vilket bekräftar autentiseringsstatusen och därför behövs ingen avsökning längre.

Autentiseringssession och kodutgång

• Autentiseringssessionen och koden upphör att gälla, användaren måste starta om autentiseringsprocessen och avsökningen med den tidigare autentiseringskoden bör stoppas omedelbart.

Ny autentiseringskod genererad

• Om användaren begär en ny autentiseringskod ogiltigförklaras den befintliga sessionen och avsökningen med den tidigare autentiseringskoden stoppas omedelbart.

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Konfigurera avsökningsmekanismens frekvens under följande villkor:

Autentisering utförd i det primära (skärm) programmet

• Det primära programmet (direktuppspelning) ska avsöka var 3-5:e sekund eller mer.

Autentisering utförd i ett sekundärt (skärm) program

• Det primära programmet (direktuppspelning) ska avsöka var 3:e till 5:e sekund.

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Lagra delar av användarens profilinformation i beständig lagring för att förbättra prestandan och minimera onödiga REST API v2-anrop.

Cachelagring bör fokusera på följande profilsvarsfält:

mvpd

• Klientprogrammet kan använda detta för att hålla reda på användarens valda TV-leverantör och fortsätta att använda det under förauktoriserings- eller auktoriseringsfaserna.
• När den aktuella användarprofilen går ut kan klientprogrammet använda det sparade MVPD-valet och be användaren bekräfta.

attribut

• Används för att anpassa användarupplevelsen baserat på olika användarmetadatanycklar (t.ex. zip, maxRating osv.).
• Användarmetadata blir tillgängliga när autentiseringsflödet har slutförts, och därför behöver klientprogrammet inte fråga en separat slutpunkt för att hämta användarmetadatainformation, eftersom den redan ingår i profilinformationen.
• Vissa metadataattribut kan uppdateras under auktoriseringsfasen beroende på MVPD (t.ex. charta) och det specifika metadataattributet (t.ex. houseID). Därför kan klientprogrammet behöva fråga Profiles-API:erna igen efter auktoriseringen för att hämta de senaste användarens metadata.

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Krav

Risker

Använd förauktoriseringsbeslut för innehållsfiltrering och aldrig för uppspelningsbeslut.

Risker som bryter mot avtal mellan Programmer, MVPD och Adobe.

Risker genom att våra övervaknings- och varningssystem kringgås.

Hantera de förbättrade felkoderna korrekt och använd åtgärdsfältet för att avgöra vilka reparationssteg som krävs.

Endast ett begränsat antal utökade felkoder kräver ett nytt försök, medan de flesta kräver alternativa upplösningar som anges i åtgärdsfältet.

Kontrollera att alla återförsöksmetoder som implementeras för att hämta beslut om förauktorisering inte resulterar i en oändlig loop och att den begränsar återförsök till ett rimligt tal (dvs. 2-3).

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Cachelagra lyckade tillståndsbeslut i minnet för att förbättra prestanda och minimera onödiga REST API v2-anrop, eftersom prenumerationsuppdateringar när programmet körs är ovanliga.

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Krav

Risker

Inhämta auktoriseringsbeslut före uppspelning - oavsett om ett förhandsauktoriseringsbeslut finns.

Tillåt att strömmar fortsätter utan avbrott även om medietoken förfaller under uppspelningen och begär ett nytt auktoriseringsbeslut som innehåller en (ny) medietoken när användaren gör sin nästa uppspelningsbegäran, oavsett om det är för samma eller en annan resurs.

Liveströmmar som körs under längre perioder kan välja att begära ett nytt auktoriseringsbeslut efter videoåtgärder som att pausa innehåll, initiera kommersiella avbrott eller ändra konfigurationer på tillgångsnivå när MRSS-strömmen ändras.

Risker som bryter mot avtal mellan Programmer, MVPD och Adobe.

Risker genom att våra övervaknings- och varningssystem kringgås.

Hantera de förbättrade felkoderna korrekt och använd åtgärdsfältet för att avgöra vilka reparationssteg som krävs.

Endast ett begränsat antal utökade felkoder kräver ett nytt försök, medan de flesta kräver alternativa upplösningar som anges i åtgärdsfältet.

Kontrollera att alla återförsöksmetoder som implementeras för att hämta auktoriseringsbeslut inte resulterar i en oändlig loop och att den begränsar återförsök till ett rimligt tal (dvs. 2-3).

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Krav

Risker

Implementera utloggnings-API:t så att användare manuellt kan logga ut, avsluta sin autentiserade profil och följa det REST API v2-åtgärdsnamn som anges för varje borttagen profil:

• För MVPD-program som stöder en utloggningsslutpunkt måste klientprogrammet navigera till angiven url i en användaragent.
• För profiler av typen"appleSSO" måste klientprogrammet hjälpa användaren att även logga ut från partnernivån (Apple systeminställningar).

Risker med att klientprogrammet inte fungerar som det ska på grund av att det saknas stöd på klientprogramsidan.

Krav

Risker

Skicka huvudet Authorization för varje REST API v2-begäran.

Risker som utlöser HTTP 401 "Obehöriga" felsvar, överbelastar systemresurser och ökar fördröjningen.

Skicka huvudet AP-Device-Identifier för varje REST API v2-begäran.

Även om begäran kommer från en server för en enhets räkning måste rubrikvärdet för AP-Device-Identifier återspegla den faktiska identifieraren för direktuppspelningsenheten.

Risker som utlöser HTTP 400-felsvar om felaktig begäran, överlagrar systemresurser och ökar fördröjningen.

Skicka rubriken X-Device-Info för varje REST API v2-begäran.

Även när begäran kommer från en server för en enhets räkning måste X-Device-Info-rubrikvärdet återspegla den faktiska informationen om direktuppspelningsenheten.

Risker som klassificeras som att de härrör från en okänd plattform och behandlas som osäkra, blir föremål för mer restriktiva regler, t.ex. kortare TTL-värden för autentisering.

Dessutom är vissa fält, till exempel direktuppspelningsenhetens connectionIp och connectionPort, obligatoriska för funktioner som Spectrum’s Home Base Authentication.

Beräkna och lagra en stabil enhets-ID som inte ändras över uppdateringar eller omstarter för huvudet AP-Device-Identifier.

För plattformar som saknar en maskinvaruidentifierare skapar du en unik identifierare från programattributen och behåller den.

Riskerar att autentiseringen går förlorad när enhetsidentifieraren ändras.

Kontrollera att du bara skickar förväntade parametrar och rubriker för REST API v2.

Risker som utlöser HTTP 400-felsvar om felaktig begäran, överlagrar systemresurser och ökar fördröjningen.

Krav

Risker

Hantera de förbättrade felkoderna korrekt och använd åtgärdsfältet för att avgöra vilka reparationssteg som krävs.

Endast ett begränsat antal utökade felkoder kräver ett nytt försök, medan de flesta kräver alternativa upplösningar som anges i åtgärdsfältet.

De mest förbättrade felkoderna i Förbättrade felkoder - REST API V2 -dokumentationen kan förhindras helt om de hanteras korrekt under utvecklingsfasen innan programmet startas.

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Riskerar att klientprogrammet fungerar som det ska på grund av att hantering av de förbättrade felkoderna saknas, vilket orsakar otydliga felmeddelanden, felaktig användarvägledning eller felaktigt reservbeteende.

Differentiera mellan hantering av HTTP-felsvar (t.ex. 400, 401, 403, 404, 405, 500) och svar på lyckade åtgärder (t.ex. 200, 2011) som innehåller utökade felkodsnyttolaster, vilket beskrivs ovan.

Endast ett begränsat antal HTTP-felkoder kräver ett nytt försök, medan de flesta kräver alternativa upplösningar.

De flesta HTTP-felsvar kan förhindras helt om de hanteras korrekt under utvecklingsfasen innan programmet startas.

Risker överbelastar systemresurser, ökar fördröjningen och kan utlösa HTTP 429-felsvar"För många begäranden".

Riskerar att klientprogrammet fungerar som det ska på grund av att hantering av de förbättrade felkoderna saknas, vilket orsakar otydliga felmeddelanden, felaktig användarvägledning eller felaktigt reservbeteende.

Krav

Risker

Utveckla och testa programmet i de officiella icke-produktionsmiljöerna för Adobe Pass Authentication:

• Förhandsproduktion
• Frigör mellanlagring

Utför en grundlig kvalitetssäkring i dessa miljöer innan du startar produktionen.

Klientprogram får inte fortsätta till versionsproduktion utan att först slutföra en fullständig validering i icke-produktionsmiljöer.

Risker med allvarliga och allvarliga fel.

Om du saknar en kort och effektiv felsökningsväg kan det hindra Adobe Support och Engineering från att snabbt komma in.

Praktik

Risker

Kontrollera åtkomsttokenens giltighet proaktivt för att uppdatera den när den har gått ut.

Kontrollera att alla återförsöksmetoder för hantering av HTTP 401-fel av typen "Obehörig" först uppdaterar åtkomsttoken innan du försöker utföra den ursprungliga begäran igen.

Risker som utlöser HTTP 401 "Obehöriga" felsvar, överbelastar systemresurser och ökar fördröjningen.

Praktik

Risker

Lagra konfigurationssvaret i minnet eller i det beständiga lagringsutrymmet under en kort tidsperiod (t.ex. 3-5 minuter) för att förbättra prestandan och minimera onödiga REST API v2-anrop.

Risker överbelastar systemresurser och ökar fördröjningen.

Praktik

Risker

Validera autentiseringskoden som skickats via användarindata i det sekundära (andra) programmet (skärmen) innan du anropar /api/v2/authenticate API under följande villkor:

Autentisering utförd i det sekundära (skärmen) programmet med förvalt mvpd

• Använd Återuppta autentiseringssession - POST /api/v2/{serviceProvider}/sessions/{code}

Autentisering utförd i sekundärt (skärm) program utan förval av mvpd

• Använd Hämta autentiseringssession - GET /api/v2/{serviceProvider}/sessioner/{code}

Klientprogrammet skulle få ett fel om den angivna autentiseringskoden skrivits fel eller om autentiseringssessionen skulle gå ut.

Riktar olika felsvar och arbetsflödesproblem under autentisering.

Se till att klientprogrammet kan hantera flera profiler genom att antingen uppmana användaren att välja en profil eller använda anpassad logik, till exempel automatiskt välja profilen med den längsta giltighetsperioden.

Risker med att klientprogrammet inte fungerar som det ska på grund av att det saknas stöd på klientprogramsidan.

Stöd för icke-grundläggande flöden om klientapplikationsverksamheten kräver:

• Försämrade åtkomstflöden (premiumfunktion)
• Tillfälliga åtkomstflöden (premiumfunktion)
• Åtkomstflöden för enkel inloggning (standardfunktion)

Risker som skapar en användarupplevelse som inte är perfekt.

Praktik

Risker

Visa tydlig användarfeedback om ett beslut om förauktorisering nekas, med meddelanden från distributörer av videoprogrammeringstjänster eller Adobe via förbättrade felkoder.

Risker som skapar en användarupplevelse som inte är perfekt.

Praktik

Risker

Validera medietoken med biblioteket Media Token Verifier.

Risker för bedrägerischeman, t.ex. strörippning.

Visa tydlig användarfeedback om ett auktoriseringsbeslut nekas med hjälp av meddelanden från distributörer av videoprogrammeringstjänster eller Adobe via förbättrade felkoder.

Risker som skapar en användarupplevelse som inte är perfekt.

Praktik

Risker

Undvik att anropa inloggnings-API automatiskt (programmatiskt) i scenarier som nekad förauktorisering eller auktorisering, eftersom utloggnings-API bara ska anropas som svar på en begäran från en direkt användare.

Risker som förvirrar användaren om att autentiseringen misslyckas.

Praktik

Risker

Återanvänd kod från REST API v1 för att beräkna enhets-ID och enhetsinformation med mindre justeringar, men kontrollera att du bara skickar förväntade parametrar och rubriker för REST API v2.

Återanvänd kod från REST API v1 för att anropa DCR-API:t för att hämta en åtkomsttoken.

-

Praktik

Risker

Kontrollera att följande grundläggande flöden har testats på olika enheter och plattformar:

Autentiseringsflöden

• Autentiseringsscenario för primärt program (skärm)
• Sekundärt autentiseringsscenario för program (skärm)

(Valfritt) Förhandsauktoriseringsflöden

• Testa scenariot för tillståndsbeslut
• Testa scenariot för att neka beslut

Behörighetsflöden

• Testa scenariot för tillståndsbeslut
• Testa scenariot för att neka beslut

Utloggningsflöden

Testa andra åtkomstflöden om tillämpligt:

• Försämrade åtkomstflöden (premiumfunktion)
• Tillfälliga åtkomstflöden (premiumfunktion)
• Åtkomstflöden för enkel inloggning (standardfunktion)

Täck de vanligaste MVPD-integreringarna (omfattar de mest använda leverantörerna).

Riskerar oförutsedda produktionsfel, särskilt på mindre frekvent testade plattformar eller sällsynta flöden som negativa scenarier.

Använd webbplatsen Adobe Developer.

-

Fas

Obligatoriskt

(Stabil) Rekommenderas

Cachelagra klientautentiseringsuppgifter

Cacheåtkomsttoken

Validera och uppdatera åtkomsttoken

Minimera hämtningar av konfigurationssvar

Konfigurationssvar för cache

Avsökningsmekanism finjusterar

Cachelagra delar av profiler

Stöd för flera profiler

Funktion för supportdegradering (om verksamheten kräver det)

Stöd för TempPass-funktionen (om verksamheten kräver det)

Stöd för enkel inloggning (om verksamheten kräver det)

Cachelagra beslut om förhandsauktorisering

Finjustera återförsöksmekanismen

Förbättra användarupplevelsen med hjälp av felkoder för nekade förauktoriseringsbeslut

Hämta auktoriseringsbeslut när användaren begär uppspelning

Finjustera återförsöksmekanism

Förbättra användarupplevelsen med felkoder för beslut om nekad auktorisering

Medietokenvalidering

Implementera utloggnings-API så att användare kan logga ut manuellt

Undvik att anropa utloggnings-API automatiskt

Obligatoriskt

(Stabil) Rekommenderas

Följ obligatoriska rubrikspecifikationer

Återanvänd kod från REST API v1

Implementera förbättrad felhantering

Implementera HTTP-felhantering

-