Deconstructing Azure PowerShell APIs with Fiddler

Developer Support

Reed Robison shows how to deconstruct Azure PowerShell operations to understand how the underlying REST calls work.


In my previous post, I talked about how Graph Explorer and Fiddler can be helpful tools when working with REST APIs. Both tools do a good job of showing you the details of request and response payloads.

Let’s look at a practical example of how this comes in handy.

There are a ton of great PowerShell libraries out there that are super easy to use. Most of these just sit on top of standard REST APIs and abstract all the details away. Recently, I ran into a use case where we couldn’t use Azure PowerShell and were looking to make equivalent calls using the REST APIs directly. In a perfect world, there would be plenty of samples to pull from – but that’s not always the case. You may also find that there is not always an obvious 1:1 mapping of the parameters when you move between PowerShell and REST APIs.

In this case, we were using Set-AzAnalysisServicesServer and were making use of the DefaultConnectionMode param. So how do you map this into the REST equivalents?

With a little digging into management operation options for Analysis Services, we find the logical equivalent would be the REST Update operation.

In the PowerShell version, DefaultConnectionMode is simply described as the “Default connection mode of an Analysis service server”. In the REST docs for Update, we find something called properties.querypoolConnectionMode which looks similar, but it’s defined as “How the read-write server’s participation in the query pool is controlled.” It takes a ConnectionMode values of All or ReadOnly, but I couldn’t find any examples. In my experience, it’s common for there to be small disparities between the PowerShell APIs and the REST APIs like this. Furthermore, it’s sometimes frustrating trying to figure out the “right” payload syntax if there isn’t a sample in the docs that use all the params you need to build on.

What else could we do to verify parameter equivalents? Where does querypoolConnectionMode go in the request body? Fiddler to the rescue.

If I want to see how a PowerShell command works underneath the hood, I could either go find the source on GitHub and dig into the code – but I’m really just curious about how it’s making the REST calls. For me, it’s more efficient to examine the calls than trace through all the code. To do this, I fire up Fiddler and examine the trace for Set-AzAnalysisServicesServer.

Breaking down the Azure PowerShell API to see what it’s doing

If I execute the following PowerShell call to perform a basic operation using DefaultConnectionMode it looks something like this:

Set-AzAnalysisServicesServer -Name “reedras” -ResourceGroupName “reredrasg” -Administrator “reedr@microsoft.com” -DefaultConnectionMode All

Looking at the Fiddler trace when I run this command, I can see it break down into three separate REST calls.

Image fiddler2

The PowerShell API issues a couple of GET calls to retrieve information on the server, and then issues a PATCH call to make any changes. It’s simply abstracting REST calls behind the scenes, but I can examine the request payload to see exactly what its sending – which is basically the information I need to build out my own REST call correctly.

The parameter I’m interested in is DefaultConnectMode which I set to All. If I change it to use the ReadOnly param and re-issue the call, I can see it reflected in the payload again – and as I suspected, it maps to the querypoolConectionMode param in the REST version of the call and I can see exactly how the payload is constructed.

When you are building code to use REST APIs, a working example of the call can save a lot of time. If you cannot find an example or the documentation doesn’t answer all your questions, it’s easy to use Fiddler and a PowerShell API to generate your own sample of a working request payload.

 

0 comments

Discussion is closed.

Feedback usabilla icon