Not compact or dense in arrangement or structure

Category Archives: MS Graph API

Postman is a popular tool for crafting up and making HTTP requests. It makes calling REST/JSON APIs like the Microsoft Graph etc… much easier. Over the years I learnt a couple of tricks that make using postman and the graph much easier that a couple of people have asked me about after seeing them in demos. So here goes.

#1. Use variables

The first thing you need to do before calling an API like MS Graph is to Authenticate. This involves app ids, secrets, tokens and other magic strings. Rather than pasting these into your requests you can set up an environment in postman that contains variables that define all these.

In an environment you can define variables like your appId, secret, tenant name etc…

Then in your requests you can use those variables, rather than copying them in, like in this call to get an access token for app-only (aka: client credential flow) calls:

Notice in the places where I need to insert these variables you use the {{ variable_name }} syntax.

#2. Automatically cache tokens

In the call made above to get an app-only access token for the graph the response payload would look like this:

Normally you would need to copy that access token out and save it into a variable for use in other calls. However, using postmans ability to run “tests” after responses come back you can run a bit of javascript that saves the content of the token into a variable automatically.

Here is the javascript:

This will run after your request is made and grabs the access token from the response and saves it in the appOnlyAccessToken variable.

Then you can make other graph calls like this one to get all users in a tenant using that variable.

Postman has built in support for helping with authentication such as OAuth etc… however i have never found it to be particularly reliable. Also you can use this same technique for other variables like a users id etc…

What a fun few days hanging out with friends and collegues in Las Vegas for the last few days. SPC NA seemed to go pretty well! I think the biggest thing for me this week was being surrounded by people who all share a common passion. That is what SPCs in the past were great at and i think some of that was rekindled this week. As always wandering the expo floor and talking with other vendors about what they are building is my favorite thing about conferences and this week was great for that. Some new faces popped up too!

For those looking for my slides from the session i did you can find them below. Unfortunatly there is a lot of content in the demos that isnt captured in the slides, but i hope it helps.

One of the most interesting announcements, at least in my mind, this week from Ignite 2016 was the news that Microsoft is adding support for Microsoft Graph API in hybrid deployments.

This means you can call the Microsoft Graph API like you would normally for Office 365 based mailboxes, for example, but have it actually connect with a mailbox that resides in an on-prem exchange server!

Let that sink in for a moment. That is pretty sweet!

Typically, if you have an application that is not deployed behind the firewall, i.e. inside the orgnaizations network, you couldnt call things like SharePoint or Exchange APIs without doing network gymnastics like VPN, reverse proxy or putting holes in your firewall (yuk).

Now with this hybrid support in the graph you can simply call internet based REST APIs and Microsoft is doing the work of facilitating that communication back to the on-prem resource.

Currently in Preview the graph only supports Mail, Calendar and Contacts in this hybrid configuration right now, however I can only imagine that more support for other endpoints like Users, SharePoint etc… will come at some point.

You also have to have Exchange 2016 CU3 servers deployed on-prem to get this support and sync your AD to Azure AD as authentication is managed this way.

You can read more about these re-reqs here: http://graph.microsoft.io/en-us/docs/overview/hybrid_rest_support

I think this is a huge benefit for those who are looking to build applications or cloud services that connect to data wherever that sits.

Couple of interesting scenarios to think about:

Mobile app that works outside the firewall was either not possible or too hard due to connectivity issues.

Cloud service web apps that you want to connect to on-prem data

Tools and Apps that can now work with data either in Office 365 or on-prem

This to me is a huge step in the right direction for Microsoft in their quest to make developers lives better in a hybrid world.

One of the pet peeves we heard no end of complaints about when i was at MS was the lack of a decent Change Log. Even just one targeted at developers. It might seem strange to people why MS haven’t done that for the whole of Office 365, but lets just say its a really hard nut to crack.

That said the great team working on the Microsoft Graph (graph.microsoft.com) APIs have been doing a nice job on the Office dev blogs keeping us up to date on changes going on in the run up to the APIs release last week.

One of the other things I have been doing to see what is changing in the API as it’s been changing is to keep an eye on the $metadata endpoint. $metadata describes all the entity types, properties and relationships etc…