Skip to content

Add ResponseHeadersVariable Parameter to Invoke-RestMethod#4888

Merged
adityapatwardhan merged 7 commits intoPowerShell:masterfrom
markekraus:InvokeRestMethodResponseHeadersVar
Sep 25, 2017
Merged

Add ResponseHeadersVariable Parameter to Invoke-RestMethod#4888
adityapatwardhan merged 7 commits intoPowerShell:masterfrom
markekraus:InvokeRestMethodResponseHeadersVar

Conversation

@markekraus
Copy link
Copy Markdown
Contributor

@markekraus markekraus commented Sep 21, 2017

closes #4845

  • Adds -ResponseHeadersVariable parameter to Invoke-RestMethod
  • Adds -RHV alias for the parameter
  • A variable with the provided name is created in the calling scope which contains the HTTP Response Headers as a dictionary constructed in the same manner WebResponseObject.Headers is constructed for Invoke-WebRequest
  • Add tests for the parameter

Documentation Needed

The new parameter will need to be documented.

@msftclas
Copy link
Copy Markdown

@markekraus,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@iSazonov iSazonov changed the title Add ResposneHeadersVariable Parameter to Invoke-RestMethod Add ResponseHeadersVariable Parameter to Invoke-RestMethod Sep 21, 2017
Copy link
Copy Markdown
Collaborator

@iSazonov iSazonov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave a comment

/// Gets or sets the ResponseHeadersVariable property.
/// </summary>
[Parameter]
[Alias("HV")]
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe 'RHV'?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm up for suggestions on this one. I was following suit with SessionVariable's SV. I would have used -HeadersVariable for the name if that wouldn't have been mistaken for -Headers

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer RHV too.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

/// </summary>
[Parameter]
[Alias("HV")]
public string ResponseHeadersVariable { get; set; }
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add any validation attributes?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SessionVariable does something similar and it doesn't have any validation. I'm not sure what value it would add. Aside from being null or empty (which is tested to set it on line 99) a variable name can be any valid string.

if (!String.IsNullOrEmpty(ResponseHeadersVariable))
{
PSVariableIntrinsics vi = SessionState.PSVariable;
vi.Set(ResponseHeadersVariable, WebResponseHelper.GetHeadersDictionary(response));
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we return ReadOnlyDictionary?
Does it make sense to return an entire response?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have seen cases where users are taking the returned dictionary, updating it, and then supplying back to further calls. I don't see much benefit. Also, System.Net.Http.Headers.HttpResponseHeaders is not read-only.

$Res = invoke-webrequest https://google.com
$Res.BaseResponse.Headers.TryAddWithoutValidation('testy','lala')
$Res.BaseResponse.Headers.GetValues('testy')

results with lala

As for the returning entire response, that would be somewhat pointless with Invoke-RestMethod, IMO. If the user needs the full response object, they can use Invoke-WebRequest. This is just adding the ability to get the response headers which many API's use to provide information along with the JSON/XML response. But, a separate PR could be made to return the response object if that is something people really want.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree that we should keep complex self-parsing usage to Invoke-WebRequest and target most common easy to use scenarios for Invoke-RestMethod. This seems fine to me.

$headers.'Content-Type' | Should Be 'text/html; charset=utf-8'
$headers.Server | Should Be 'Kestrel'
}
It "Verifies Invoke-RestMethod supports -HV alias" {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We never test parameter aliases. If we want test parameter aliases we must create one complex test. I think we should remove the test.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Copy link
Copy Markdown
Member

@adityapatwardhan adityapatwardhan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

/// Gets or sets the ResponseHeadersVariable property.
/// </summary>
[Parameter]
[Alias("HV")]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer RHV too.

Copy link
Copy Markdown
Member

@SteveL-MSFT SteveL-MSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution! My comments are not blocking.

/// </summary>
[Parameter]
[Alias("RHV")]
public string ResponseHeadersVariable { get; set; }
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the guideline is to still use singular ResponseHeaderVariable unless the output is always not singular. It also seems that HTTP 1.1 calls the whole thing a Response Header and the individual headers as fields.

Copy link
Copy Markdown
Contributor Author

@markekraus markekraus Sep 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I chose Headers because we are using the -Headers parameter as well as WebResponseObject.Headers (which this provides parity for) and HttpResponseMessage.Headers & HttpResponseMessage.Content.Headers (which the dictionary is generated from). I can change it, but it would be the odd-man-out.

If the resulting variable provided a string with the raw Response Header, I would agree. But I think ResponseHeadersVariable makes clear that it is collection of some kind.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with it

if (!String.IsNullOrEmpty(ResponseHeadersVariable))
{
PSVariableIntrinsics vi = SessionState.PSVariable;
vi.Set(ResponseHeadersVariable, WebResponseHelper.GetHeadersDictionary(response));
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree that we should keep complex self-parsing usage to Invoke-WebRequest and target most common easy to use scenarios for Invoke-RestMethod. This seems fine to me.

$response = Invoke-RestMethod -Uri $uri -ResponseHeadersVariable 'headers'

$headers | Should Not Be 'prexisting'
$headers | Should Not BeNullOrEmpty
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this test isn't needed as the next line would fail

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. and removed from the other test as well.

@adityapatwardhan adityapatwardhan merged commit 3237d43 into PowerShell:master Sep 25, 2017
@adityapatwardhan
Copy link
Copy Markdown
Member

@markekraus Thanks for your contribution.

@markekraus markekraus removed the Documentation Needed in this repo Documentation is needed in this repo label Oct 20, 2017
@markekraus markekraus deleted the InvokeRestMethodResponseHeadersVar branch January 19, 2018 18:58
@pr3sidentspence
Copy link
Copy Markdown

@markekraus Resposne typo still exists in the body of OP.

Adds -ResposneHeadersVariable parameter ...

@iSazonov
Copy link
Copy Markdown
Collaborator

iSazonov commented Jan 1, 2019

Fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow Capture of Response Headers with Invoke-RestMethod

6 participants