Varför använda en Microsoft Graph SDK

När Dev Proxy identifierar att ditt program gör Microsoft Graph API-begäranden utan att använda ett SDK föreslår det att du migrerar till en SDK. Den här vägledningen finns eftersom Microsoft Graph SDK:er avsevärt förenklar arbetet med Microsoft Graph-API:er och hjälper dig att skapa mer robusta program.

Fördelar med Microsoft Graph SDK:er

Microsoft Graph-SDK:er ger många fördelar jämfört med att göra råa HTTP-anrop.

Inbyggd autentiseringshantering

SDK:er integreras med autentiseringsbibliotek som Microsoft Authentication Library (MSAL), hantering av tokenförvärv, uppdatering och hantering automatiskt. Du behöver inte implementera OAuth 2.0-flödet manuellt eller oroa dig för att token upphör att gälla.

Automatisk omförsökslogik för strypning

Microsoft 365-tjänster implementerar throttling för att säkerställa tillförlitligheten hos tjänsten. När ditt program får ett 429 Too Many Requests svar hanterar SDK:t automatiskt återförsök med lämpliga fördröjningar för backoff, med respekt för rubriken Retry-After som Microsoft Graph returnerar.

Korrekt sidnumreringshantering

Många Microsoft Graph-slutpunkter returnerar sidnumrerade resultat. SDK:er tillhandahåller inbyggda iteratorer som transparent hanterar hämtning av efterföljande sidor, så du behöver inte spåra @odata.nextLink värden manuellt och göra andra begäranden.

Typsäkerhet och IntelliSense

SDK:er tillhandahåller starkt skrivna modeller för begäranden och svar, vilket ger dig IntelliSense-stöd i din IDE. Typmodeller minskar felen och påskyndar utvecklingen genom att identifiera problem vid kompilering i stället för körningstid.

Stöd för batchbearbetning

SDK:er stöder batchbearbetning av flera begäranden i ett enda HTTP-anrop, vilket minskar nätverkskostnaderna och förbättrar prestandan. Batchbearbetning hjälper dig också att hålla dig inom begränsningsgränserna genom att minska antalet enskilda begäranden.

Deltafrågor

SDK:er förenklar implementeringen av deltafrågor som gör att du effektivt kan synkronisera dataändringar sedan din senaste begäran. Att använda deltafrågor är avgörande för att skapa dynamiska program som behöver synkroniseras med Microsoft 365-data.

Mellanprogramsarkitektur för anpassning

SDK:er använder en anpassningsbar pipeline för mellanprogram för att lägga till loggning, ändra rubriker, implementera anpassade återförsöksprinciper eller mata in andra beteenden utan att ändra programkoden.

Konsekventa API-mönster

SDK:er ger konsekventa mönster på olika plattformar och språk, vilket gör det enklare att dela kunskap mellan gruppmedlemmar och mellan projekt.

Vad råa HTTP-anrop missar

När du gör råa HTTP-anrop till Microsoft Graph måste du implementera flera viktiga funktioner själv.

Manuell omprövning av logikimplementering

Utan ett SDK måste du implementera omprövningslogik för hantering 429 responses, inklusive:

• Parsa rubrikvärdena Retry-After
• Implementera exponentiell avbackning
• Hantera olika felscenarier
• Undvika återförsök av stormar under tung belastning

Manuell sidnumreringshantering

Du måste:

• Kontrollera varje svar för @odata.nextLink
• Gör fler begäranden för varje sida
• Aggregera resultat över sidor
• Hantera partiella fel under paginering

Kodmall för felhantering

Microsoft Graph kan returnera olika felsvar med olika strukturer. Utan SDK måste du:

• Parsa felsvarskroppar
• Hantera olika HTTP-statuskoder på rätt sätt
• Extrahera meningsfulla felmeddelanden för loggning
• Implementera återställningsbeteende för oväntade fel

Autentiseringskomplexitet

För att hantera autentisering manuellt krävs:

• Implementera OAuth 2.0-flöden
• Lagra och skydda tokens
• Hantera tokenuppdatering före förfallodatum
• Hantera olika autentiseringsscenarier (delegerade jämfört med programbehörigheter)

Tillgängliga SDK:er

Microsoft tillhandahåller officiella SDK:er för följande plattformar:

Alternativ till att använda en SDK

Även om SDK:er rekommenderas för de flesta scenarier finns det fall där andra metoder kan passa bättre:

Kiota-genererad klient

Om ditt program bara använder en liten delmängd av Microsoft Graph-API:er kan du överväga att generera en klient med Kiota i stället för att använda hela SDK:t. Kiota genererar en lätt, starkt typad klient som är skräddarsydd för de specifika API:er du behöver, vilket minskar ditt beroendeavtryck samtidigt som du får typ-säkerhet och förfrågningsbygge.

Minimal API-användning

Om du skriver ett snabbskript eller verktyg som bara gör ett fåtal API-anrop är det inte säkert att kostnaderna för att konfigurera ett SDK motiveras. I dessa fall kan direkta HTTP-anrop vara enklare. Du behöver dock fortfarande hantera autentiserings - och felsvar själv, vilket snabbt kan öka komplexiteten även för enkla skript.

Språk som inte stöds

Om du använder ett programmeringsspråk som inte har någon officiell SDK måste du göra direkta HTTP-anrop. Du kan också överväga att använda Kiota för att generera en klient för ditt språk om Kiota stöder det.

När SDK:t inte har stöd för en specifik funktion ännu

Microsoft Graph lägger kontinuerligt till nya funktioner. Ibland kanske ett nytt API eller en ny funktion inte har ett flytande API i SDK:n omedelbart. I de flesta fall kan du fortfarande använda SDK:t för att göra godtyckliga begäranden med hjälp av en sökvägssträng, vilket ger dig fördelarna med SDK:ts mellanprogram (autentisering, återförsök, loggning) utan att behöva skriva begärandebyggare. Om SDK:t inte stöder begäran alls kan du återgå till att dirigera HTTP-anrop tills SDK-stöd har lagts till.

Prestandakänsliga miljöer

I scenarier som serverlösa funktioner eller gränsberäkning där kallstartstid och paketstorlek spelar roll kan en lättare metod med Kiota-genererade klienter eller direkta HTTP-anrop vara lämpligare.

Nästa steg

Lär dig hur du uppdaterar ditt program för att använda ett Microsoft Graph SDK:

Relaterat innehåll

• Översikt över Microsoft Graph SDK
• Välj en Microsoft Graph-autentiseringsprovider
• Installera en Microsoft Graph SDK
• Metodtips för att arbeta med Microsoft Graph