Allow caller to Specify desired OutputType

[georgend]

Add -OutputType [HashTable | PSObject | HttpResponseMessage | Json] parameter to enable caller decide preferred format. HashTable is the default.
PSObject for a Single Entity

PSObject for a collection

HttpResponseMessage

Resolves #480 #479 #454

[KirkMunro]

I think you need to simplify the variables that are used here, and fit them more into existing PowerShell paradigms.

For example, instead of:

• returning a custom PowerShell object by default
• returning the HttpResponseMessage if the -Raw switch is used
• returning the JSON string if the -Json switch is used

Why not provide an -OutputType parameter that is an enumeration. The enumeration would have three values: PSObject, Json, and HttpResponseMessage. The default value would be PSObject. This would allow the cmdlets to work like they already do today, while allowing users to decide if they want the raw JSON or the HttpResponseMessage object, without having to deal with multiple parameters that are mutually exclusive of one another.

Also, for the -OriginalRequestClone "createRequestClone" parameter that creates a "magic" $requestClone variable in the current scope, that is not consistent with existing methods used in PowerShell is used to output values into a variable. For example, PowerShell supports common -OutVariable, -ErrorVariable, -WarningVariable, and -PipelineVariable parameters that are used to redirect various things into PowerShell variables. The user provides the variable name, and the content is assigned to that variable. The user can choose to overwrite the content of the variable, or add content to the variable. For instance, consider this script:

# Get some services, output them to the console, and store them in $myServices
gsv -name wuauserv,bits -ov myServices
# Show the services that were stored
$myServices
# Get some more services, and _add_ them to the myServices variable (note the "+" prefix)
gsv -name k* -ov +myServices
# Show the updated services collection
$myServices

This is the model that should be followed for requesting the HTTP request. If you were to apply this to the Graph cmdlets, the command might look like this:

# Get users, output them, and capture the HTTP request
Get-MgUser -HttpRequestVariable httpRequest
# Look at the request
$httpRequest

In this scenario, you are not dealing with data streams, so I don't think there is a lot of value in supporting the "+" prefix to add another request to an existing variable, other than to maintain consistency with the model that is already in place for capturing content in variables, so it's up to you whether or not you want to add that.

I think these two sets of changes would make for a much better experience for PowerShell scripters that is easier to learn and use.

[ddyett]

@finsharp do we have some limitation on the azure machines we need to look at. The errors for the integrated build seem to be indicating that.