What is Microsoft Graph and Why Do I Care?
If you’re a developer on the Microsoft stack then you’ve likely heard of Microsoft Graph, but you might not yet have had occasion to use it, or really understand what it is, or why it’s so important. This post will show you why it’s a hugely important part of developing Microsoft-based solutions today, and how you can get started in Graph.
My theory is that Graph is the most important developer platform you can build on today. Why do I say this? Because Graph gives you access to data, and data is the most important asset when it comes to building solutions today.
Everywhere we look, people are demanding more and more access to data, delivered to them intelligently, in a timely manner and in a format that helps them make decisions. Gone are the days when you could write a Line of Business application which only surfaced half the information needed to make a strategic decision, or didn’t give a user everything they needed to get their work done. Driven by ever more sophisticated consumer apps, users are demanding that their LOB applications work harder for them.
If your users are on the Microsoft 365 stack and using Office 365 workloads, then Microsoft potentially has access to a huge amount of data. Not only the actual files, chats, calls and meetings that are taking place, but also all the meta information that goes alongside that – the devices they use, their free/busy times, the people they work with etc.
But here’s the thing. Microsoft isn’t in the business of keeping all this data and mining it for commercial gain. They would rather offer it to you, the enterprise developer, for you to build Line of Business applications which take advantage of that data. It’s your data, and Microsoft is providing you a platform to consume it.
That’s what Graph is. Graph is a huge API that spans the Microsoft 365 estate, providing developers with access to a wide range of different information.
Graph is nothing more (and nothing less) than an API endpoint. It has replaced the myriad of different Microsoft APIs which existed to access different parts of the Microsoft Cloud and now provides a common endpoint with a common authentication process, common schema, and common permissions model.
The best way to really see Microsoft Graph in action and to get a feel for how powerful it can be, is to use the Graph Explorer. This is a test site, designed to showcase the different API calls you can make, and give you a chance to execute them using either test data, or your own.
Navigate to: developer.microsoft.com/graph/graph-explorer to get started. By default, a test account is used, but you can also Sign In to use your own credentials.
Down the left-hand side, you can see some examples of calls you can make. You can also click “show more samples” and choose a workload that you’re interested in. Just by looking at the list of samples you can see how powerful Graph can be and how much information you have at your fingertips:
Remember that all these calls are just HTTPS request/response calls. You can consume them in any application or service. Hopefully, you’re starting to see how powerful this API can be, as it spans so many parts of a user’s work experience.
Because Graph is secured using permissions (you need to have access to the things you’re asking Graph for, you may find that if you’re using your own credentials, you run into commands that throw permission errors.
Permissions in Graph are handled within Applications, which can be created and managed inside Azure and are the topic of another blog post (either on this site if I can find time, but it’s well covered elsewhere).
Once you’ve understood the amount of information that’s available to you in Graph, and got some ideas for which parts of Graph might be interested, it’s time to find out more. The Graph documentation and especially the API reference is really helpful because it’s in a standard format across the whole namespace, which each call having its own page, showing exactly how to use it, what permissions are required, and what responses can be expected.
What about Beta?
If you look through the documentation you may notice that there is an option to show either v1.0 of the docs, or beta. Also, in the Graph Explorer, you can change the namespace to /beta.
The /beta namespace contains Graph calls which are new and in Preview. You shouldn’t use these in Production, and it’s expected that they may change without warning, but if you’re developing a new application, Microsoft gives you a way to call them today before you go into production. In my experience, the documentation for the /beta calls is as good as it is for the v1.0 calls, which is really useful when you’re building solutions and using new calls.
SDKs, Libraries, Samples
But wait, that’s not all! There are also SDKs, libraries and sample code in more than 20 languages, including C#, Visual Basic.Net, Java, Node.js, Ruby and Swift. To find what you’re looking for navigate to the dedicated Graph Gallery: developer.microsoft.com/graph/gallery
Graph Postman Collections
Finally, this blog post would not be complete without mentioning a brand new resource now available to Graph developers.
You may already be familiar with Postman, an API development environment. It makes working with APIs easier.
The Graph team have recently released a Postman Collection that you can import and use with any application you have created in your Microsoft 365 Tenant. The initial release has almost all of the samples for user delegated authorization flow that are in the current Graph Explorer. This includes: Applications (beta), Batch, Events, Files, Groups, Insights, Mail, Notebooks, Extensions, People, Planner, Security, SharePoint, Subscriptions, Tasks, Teams and Users.
For more information on this, watch the short Getting Starting video: