Utveckla med API:er för Media Services v3

  • Artikel

Media Services-logotyp v3

Varning

Azure Media Services dras tillbaka den 30 juni 2024. Mer information finns i AMS Pensionsguide.

Som utvecklare kan du använda klientbibliotek för (.NET, Python, Node.js, Java och Go) som gör att du kan interagera med REST-API:et för att enkelt skapa, hantera och underhålla anpassade mediearbetsflöden. Media Services v3 API 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:et för Media Services direkt i din egen bibliotekskod, eftersom det skulle kräva att du implementerar den fullständiga logiken för återförsök i Azure Resource Management och förstår 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 osv. – automatiskt och minskar risken för att du får problem med omförsökslogik eller misslyckade API-anrop. Klient-SDK:erna hanterar redan detta åt dig.

Å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 mellannivå 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. API:et kan nås med rollen Läsare , men endast Get - eller List-åtgärder är 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 app och tjänstens huvudnamn ska finnas i samma klientorganisation. När du har skapat appen ger du appen Deltagare eller Ägare åtkomst till Media Services-kontot.

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

I följande bild representerar talen flödet av begäranden i kronologisk ordning:

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

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

    • Azure AD klientslutpunkt.
    • 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 nödvändiga värden finns i Åtkomst till Azure Media Services API.

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

  3. Mellannivån skickar 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 kan 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 Namngivning av 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-namn. Orsaken till dessa krav är att filerna kan kopieras från Blob Storage till en lokal NTFS-disk för bearbetning.

Långvariga åtgärder

De åtgärder som markerats med x-ms-long-running-operation i Azure Media Services swagger-filerna är tidskrävande å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 överförts får du ett "201 Created" och måste söka efter slutförande av åtgärden med hjälp av det returnerade åtgärds-ID:t.

I artikeln spåra asynkrona Azure-åtgärder beskrivs på djupet 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 en tidskrävande åtgärd har startats måste den slutföras innan en efterföljande tidskrävande åtgärd startas på samma LiveEvent eller eventuella associerade liveutdata. För livehändelser med flera liveutdata måste du vänta på slutförandet av en tidskrävande åtgärd på en liveutdata innan du utlöser en tidskrävande åtgärd på en annan liveutdata.

SDK:er

Anteckning

Azure Media Services v3 SDK:er är inte garanterade trådsäkra. När du utvecklar en app med flera trådar 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 (till exempel 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

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, support tillhandahålls av 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örandekod eller kontakt opencode@microsoft.com med andra frågor eller kommentarer.

Filtrering, ordning, växling av Media Services-entiteter

Se Filtrering, beställning, växling av Azure Media Services-entiteter.

Få hjälp och support

Du kan kontakta Media Services med frågor eller följa våra uppdateringar med någon av följande metoder: