Microsoft Graph PowerShell SDK or Invoke-RestMethod

Microsoft introduced the Microsoft GraphAPI in 2015 as a unified RESTful API endpoint to access data and services across Microsoft 365, Azure, and other Microsoft cloud platforms. The Graph API provides a single endpoint (https://graph.microsoft.com) to interact withservices like Entra ID, Exchange Online, SharePoint, Teams, and more.

Initially, administrators used raw REST API calls with PowerShell’s Invoke-RestMethod (and Invoke-WebRequest) to interact with the Microsoft Graph API. These cmdlets work well—they are somewhat advanced, but once you get the hang of them, you can accomplish almost anything within Graph. They are still preferred by many administrators, mainly because they offer low-level control, and scripts written with them remain useful as long as Graph is available. In contrast, several modules, such as the Azure AD module,have become obsolete, requiring scripts that depend on them to be rewritten.

‍

Microsoft Graph Powershell SDK

Invoke-RestMethod is still widely used (and for good reasons), offering flexibility for complex API interactions. However, Microsoft provides a PowerShell SDK consisting of cmdlets that simplify interaction with the Graph API. These cmdlets in the Microsoft Graph PowerShell SDK are autogenerated using AutoRest on a monthly (partly bi-weekly) schedule to incorporate new API endpoints, ensuring access to the latest Graph API features.

‍

Quick History

In 2020, Microsoft released the first version of the Microsoft Graph PowerShell SDK. This version introduced Certificate-Based Authentication (CBA), support for delegated and application permissions, Managed Identities, and modern authentication using OAuth 2.0.

In July 2023, version 2.0 was released. It introduced the Connect-MgGraph authentication cmdlet, as well as modularization and performance enhancements, such as HTTP/2 support and prefixes for v1.0 and beta cmdlets, reducing ambiguity in scripting. (For example, Get-MgUser calls the stable API, while Get-MgBetaUser calls the beta API).

In January 2024, version 2.13 introduced improved certificate discovery and validation, making it easier to authenticate using certificates. In May 2024, version 2.19 restored backward compatibility with previously deprecated cmdlets, ensuring smoother transitions for existing scripts.

These are just some of the historical changes; for a full breakdown, see the release log on GitHub.

‍

Microsoft Graph PowerShell SDK vs Invoke-RestMethod

In the previous section, we touched on some benefits and drawbacks of choosing between the Graph PowerShell SDK and Invoke-RestMethod. In this section, we'll take a deeper dive to explore the differences in more detail.

‍

Authentication

One of the major differences is authentication. When using Invoke-RestMethod, you need to write and maintain your own authentication logic. This can be complex and security-sensitive. You'll often see code with secrets embedded, which, of course, is never considered best practice. However, due to the complexity, this happens frequently. For modern authentication, if you need a longer-lived session, you must account for obtaining new access tokens using your refresh token. To manage this properly, you need a solid understanding of OAuth 2.0 and OpenID Connect protocols. Otherwise, you’re reusing code and hoping for the best.

The Microsoft Graph PowerShell SDK offers the Connect-MgGraph cmdlet, which handles authentication for you. It supports device code flow, Managed Identity, certificate authentication, and more. Built on top of the MSAL library, the SDK is maintained by Microsoft's Security team and OAuth/OpenID Connect experts. The Connect-MgGraph cmdlet manages access tokens, refresh tokens, SSO, and other authentication tasks behind the scenes. This is a major benefit, as it makes your scripts inherently more secure.

This is especially beneficial because scripts don’t need to include authentication code. You simply direct users of the script to use Connect-MgGraph, and they can fulfill all their authentication needs, from interactive logins to automated authentication. As a result, you only need to focus on the actual business logic in your scripts. In the next part of this blog post series, we will discuss authentication in more detail with the Microsoft Graph PowerShell SDK.

‍

Code Longevity

Writing and refining complex scripts takes significant time and effort. Once you’ve completed your script, it’s crucial to ensure that it remains useful for the long term—not only for yourself but also for others who may use it. However, when the underlying modules or SDKs undergo non-backward-compatible changes, your script might need to be updated to keep it functioning.

We saw this when the Microsoft Graph PowerShell SDK version 2 was released. It introduced changes such as a new naming scheme for beta endpoints and the deprecation of previously used modules, requiring updates to existing scripts.

In contrast, Invoke-RestMethod is quite stable. Since you are primarily interacting with raw REST endpoints, changes to these endpoints don't happen frequently enough to impact your scripts in most cases. If an endpoint is moved or deprecated, it will eventually stop working—but these changes are rare. This stability makes Invoke-RestMethod a good choice for long-term code that doesn't require frequent updates or dependency management.

‍

Paging, Batching, and General Optimizations

When working with large datasets in the Microsoft Graph API, efficient data retrieval is crucial to minimize latency and resource consumption. Paging refers to the practice of breaking large datasets into smaller chunks or "pages" because the Graph API has a limitation on how much data it returns per page. To retrieve the complete dataset, you need to handle paging to request subsequent pages.

The Microsoft Graph PowerShell SDK simplifies this process by handling both paging and batching automatically behind the scenes. The SDK takes care of requesting additional pages of data as needed, so users can focus on extracting the information they need without writing complex pagination logic. Additionally, when dealing with multiple requests, the SDK supports batching, which allows you to bundle multiple API calls into a single HTTP request, significantly improving performance and reducing the number of network calls.

In contrast, Invoke-RestMethod requires manual intervention for paging and batching. While it's possible to implement paging by checking for @odata.nextLink in the API response, the process isn't automated, which increases complexity in your code. For batch requests, you need to create a custom payload to send multiple API calls in a single request. This gives you more flexibility but requires additional effort and a deeper understanding of how batching works with the Graph API. As a result, while Invoke-RestMethod allows for complete control over the paging and batching process, the Graph PowerShell SDK streamlines these operations, offering a more user-friendly and optimized solution for most use cases.

‍

Which One to Pick?

As with many decisions in technology, the answer depends on your needs. There’s nothing inherently wrong with using the low-level Invoke-RestMethod cmdlet, especially if you’re comfortable navigating its complexities. For advanced coders who (indirectly) sell their code, avoiding breaking changes is essential, and flexibility in advanced functionalities allows customization for specific customers.

On the other hand, for most regular users and contributors, the Microsoft Graph PowerShell SDK is likely a better fit. It offers a streamlined experience, reducing the risk of introducing vulnerabilities and providing built-in optimizations for advanced tasks. This allows you to focus more on solving business problems rather than managing low-level authentication.

‍

Conclusion

The Microsoft Graph PowerShell SDK simplifies working with Microsoft Graph API by handling authentication, pagination, batching, and other optimizations automatically. While Invoke-RestMethod provides greater flexibility and long-term script stability, it requires more manual effort, particularly for authentication and handling API responses. For most users, the SDK is the better choice, as it reduces complexity, minimizes security risks, and ensures compatibility with future Microsoft Graph updates. However, advanced users who need full control over their API interactions may still prefer Invoke-RestMethod for its flexibility and low-level access.

Microsoft has shown a strong commitment to the Microsoft Graph PowerShell SDK. Regular updates and new features are continuously being added, with much of the process being automated, as discussed. Furthermore, the Graph PowerShell SDK is open-source and has a growing community of contributors who are constantly improving and expanding its functionality. Given these factors, I have confidence (perhaps wishful thinking! 🤞) that the Microsoft Graph PowerShell SDK is here to stay.

‍