Utveckla med API:er för Media Services v3

  • Artikel
  • 5 minuter för att läsa

media services-logotyp v3

Letar du efter Media Services v2-dokumentation?

Som utvecklare kan du använda klientbibliotek för (.NET, Python, Node.js, Java, Go och Ruby) som gör att du kan interagera med REST API för att enkelt skapa, hantera och underhålla anpassade mediearbetsflöden. Den Media Services v3-API:et baseras på OpenAPI-specifikationen (kallades tidigare swagger).

Den här artikeln beskriver regler som gäller för entiteter och API:er när du utvecklar med Media Services v3.

Varning

Vi rekommenderar inte att du försöker omsluta REST API för Media Services direkt i din egen bibliotekskod. Om du gör det i produktionssyfte måste du implementera den fullständiga omprövningslogiken för Azure Resource Management och förstå hur du hanterar långvariga åtgärder i Azure Resource Management-API:er. Detta hanteras av klient-SDK:er för olika språk – .NET, Java, TypeScript, Python, Ruby osv. – automatiskt och minskar risken för att du får problem med logik för omtrering eller misslyckade API-anrop. Alla klient-SDK:er hanterar detta åt dig redan. Postman-samlingen tillhandahålls mer som ett undervisningsverktyg och för att visa dig vad klient-SDK:erna faktiskt gör på kabeln under utvecklingen med de olika klient-SDK:erna.

Åtkomst till Azure Media Services-API:et

Du måste autentiseras innan du kan få åtkomst till Media Services-resurser och Media Services-API:et. Media Services stöder Azure Active Directory-baserad (Azure AD) autentisering. Två vanliga autentiseringsalternativ:

  • Autentisering av tjänstens huvudnamn: Används för att autentisera en tjänst (till exempel webbappar, funktionsappar, logikappar, API:er och mikrotjänster). Program som ofta använder den här autentiseringsmetoden är appar som kör daemon-tjänster, tjänster på mellan nivå eller schemalagda jobb. För webbappar bör det till exempel alltid finnas en medelnivå som ansluter till Media Services med tjänstens huvudnamn.
  • Användarautentisering: Används för att autentisera en person som använder appen för att interagera med Media Services-resurser. Den interaktiva appen bör först fråga efter användarens autentiseringsuppgifter. Ett exempel är en hanteringskonsolapp som används av behöriga användare för att övervaka kodningsjobb eller liveuppspelning.

Media Services-API:et kräver att användaren eller appen skickar REST API-begäranden för att få åtkomst till Media Services-kontoresursen och att rollen Deltagare eller Ägare används. Det går att komma åt API:et med rollen Läsare men då är endast åtgärderna Get eller List tillgängliga.Mer information finns i Rollbaserad åtkomstkontroll i Azure (Azure RBAC) för Media Services konton.

I stället för att skapa tjänstens huvudnamn kan du överväga att använda hanterade identiteter för Azure-resurser så att du kan komma åt Media Services-API:et via Azure Resource Manager. Mer information om hanterade identiteter för Azure-resurser finns i Vad är hanterade identiteter för Azure-resurser?.

Azure AD-tjänstens huvudnamn

Azure AD-appen och tjänstens huvudnamn ska finnas i samma klientorganisation. När du har skapat appen ger du appens deltagare eller ägarroll åtkomst till Media Services konto.

Om du inte är säker på om du har behörighet att skapa en Azure AD-app kan du läsa Nödvändiga behörigheter.

I följande bild representerar talen flödet för begärandena i kronologisk ordning:

Appautentisering på mellannivå med AAD från ett webb-API

  1. En app på mellannivå begär en Azure AD-åtkomsttoken som har följande parametrar:

    • Slutpunkt för Azure AD-klientorganisation.
    • Media Services resurs-URI.
    • Resurs-URI för REST Media Services.
    • Azure AD-appvärden: klient-ID och klienthemlighet.

    Information om hur du hämtar alla värden som behövs finns i Access Azure Media Services API.

  2. Azure AD-åtkomsttoken skickas till mellannivån.

  3. Mellannivån skickar en begäran till Azure Media REST API med Azure AD-token.

  4. Mellannivån hämtar tillbaka data från Media Services.

Exempel

Se följande exempel som visar hur du ansluter med Azure AD-tjänstens huvudnamn:

Namngivningskonventioner

Azure Media Services v3-resursnamn (till exempel tillgångar, jobb, transformeringar) är föremål Azure Resource Manager-namnbegränsningar. I enlighet med Azure Resource Manager är resursnamnen alltid unika. Därför kan du använda alla strängar som unika identifierare (till exempel GUID) för ditt resursnamn.

Media Services resursnamn får inte innehålla: "<", ">", "%", "&", ":", "\", "?", "/", "*", "+", ".", det enkla citattecknet eller några kontrolltecken. Alla andra tecken tillåts. Maxlängden för ett resursnamn är 260 tecken.

Mer information om Azure Resource Manager finns i Namngivningskrav och Namngivningskonventioner.

Namn på filer/blobar i en tillgång

Namnen på filer/blobar i en tillgång måste följa både kraven för blobnamn och NTFS-namnkrav. Orsaken till dessa krav är att filerna kan kopieras från bloblagringen till en lokal NTFS-disk för bearbetning.

Långvariga åtgärder

De åtgärder som x-ms-long-running-operation markerats med i Azure Media Services swagger-filer är långvariga åtgärder.

Mer information om hur du spårar asynkrona Azure-åtgärder finns i Async-åtgärder.

Media Services har följande långvariga åtgärder:

När en lång åtgärd har skickas får du ett "201 Skapad" och måste avssöka efter åtgärdsslut med hjälp av det returnerade åtgärds-ID:t.

Artikeln spåra asynkrona Azure-åtgärder förklarar i detalj hur du spårar status för asynkrona Azure-åtgärder via värden som returneras i svaret.

Endast en långvarig åtgärd stöds för en viss livehändelse eller någon av dess associerade liveutdata. När den har startats måste en långvarig åtgärd slutföras innan en efterföljande långvarig åtgärd startas på samma LiveEvent eller eventuella associerade liveutdata. För livehändelser med flera liveutdata måste du vänta på att en långvarig åtgärd ska slutföras på en liveutdata innan du utlöser en långvarig åtgärd på en annan liveutdata.

SDK:er

Anteckning

De Azure Media Services v3-SDK:erna är garanterat inte trådsäkra. När du utvecklar en flertrådig app bör du lägga till din egen trådsynkroniseringslogik för att skydda klienten eller använda ett nytt AzureMediaServicesClient-objekt per tråd. Du bör också vara försiktig med problem med flera trådar som introduceras av valfria objekt som tillhandahålls av koden till klienten (t.ex. en HttpClient-instans i .NET).

SDK Referens
.NET SDK .NET-referens
Java SDK Java-referens
Python SDK Python-referens
Node.js SDK Node.js-referens
Go SDK Go-referens
Ruby SDK

Se även

Azure Media Services Explorer

Azure Media Services Explorer (AMSE) är ett verktyg som är tillgängligt för Windows-kunder som vill lära sig om Media Services. AMSE är ett Winforms-/C#-program som laddar upp, laddar ned, kodar och strömmar VOD- och live-innehåll med Media Services. AMSE-verktyget är till för klienter som vill testa Media Services utan att skriva någon kod. AMSE-koden tillhandahålls som en resurs för kunder som vill utveckla med Media Services.

AMSE är ett projekt med öppen källkod och får support från communityn (problem kan rapporteras till https://github.com/Azure/Azure-Media-Services-Explorer/issues). Det här projektet använder sig av Microsofts uppförandekod för öppen källkod. Mer information finns i Vanliga frågor och svar om uppförandekoden eller kontakta om du har andra frågor eller opencode@microsoft.com kommentarer.

Filtrering, ordning, växling av Media Services entiteter

Se Filtrering, ordning, växling av Azure Media Services entiteter.

Ställ frågor, ge feedback, få uppdateringar

Ta en Azure Media Services community-artikeln om du vill se olika sätt att ställa frågor, ge feedback och få uppdateringar om Media Services.

Se även

Information om hur du hämtar alla värden som behövs finns i Access Azure Media Services API.

Nästa steg