Vscode-restclient: Provide possibility to extract values from response

[akalcik]

It will be helpful to have a possibility to extract items from response into the variables. For example I want test API which is protected by Authorization Server. Today, to access the API, I need start request to Authorization Server, copy the claim from response into the new request and start new API request. It will be nice if I can extract the claim into the variable.

[Huachao]

@akalcik nice suggestion, I will consider it carefully 😄

[pfemiani]

It would be really helpful to get values from responses. One idea could be to allow naming of Requests, and a named request would result in its own Response tab/doc (rather than trying to manage response variables/scopes/etc), and you could perhaps pull values via {{RequestName:ResponseValueLocation}} where response value location might be in "dot" notation for Json or XPath for Xml responses?

### Auth
POST https://auth.server.com/auth HTTP/1.1
Authorization: BLAH My:Creds
Accept: application/json

### MyInfo
GET https://api.server.com/me HTTP/1.1
Authorization: TOKEN {{Auth:data.AuthToken}}
Accept: application/json

Theoretically you could then infer request dependency, so if Auth response doesn't exist yet it could execute automatically before the MyInfo request, but that is really just a nice-to-have.

[pcornier]

It would be a great improvement 🤘, I really want to get rid of Postman in my workflows.

[fmartingr]

I'm also looking forward to this. While I agree with @pfemiani proposal, a simpler approach could be to allow saving response to a variable and then using it:

POST url/auth -> authResponse
Content-Type: application/json

{...}

###

POST my/protected/endpoint
Authorization: Token {{authResponse.json.token}}

I'm not sure how other rest client for other editors resolve this (if they do at all) but it will be an awesome addition.

[lee-fu]

This would be an awesome addition. I would like to assert against the response as a sort of basic contract test like so:

POST ...
...
const expected = {...};
assert({response} === expected, 'The response should equal the expected payload');

[cbrevik]

Hi @Huachao!

Love this extension, use it daily, and I would love this feature as well.

I tried to do a really naive proof-of-concept implementation of this here: https://github.com/cbrevik/vscode-restclient/commit/dedaf550aa7f2b1e8febef2fdbbe9a478b321118

It's inspired by @fmartingr's suggestion of "piping" the response to a variable name like POST url/auth -> authResponse.

That implementation should work with something like:

@baseUrl = https://jsonplaceholder.typicode.com
GET {{baseUrl}}/posts/1 -> thisResponse

###

GET {{baseUrl}}/users/{{thisResponse.body.userId}}

By caching the whole response it would give you access to other parts like headers.

Currently it expects the body to be JSON though, added a JSON.parse if dotted part is equal to "body". Like I said, really naive implementation without any error-checking etc.

I'd be interested in discussing approach here though 👍

[fmartingr]

Wow @cbrevik ! I did fiddle around a bit with the extension but didn't get this far because of how variables are parsed on request, didn't occur to me assigning the name on the response store, very nice!

As for the problem of the response content, maybe we can leave that to the user, just providing some helper attributes rawBody/jsonBody/xmlBody/..., handling when conversion fails because the content do not match or just returning nothing if the Content-Type header do not matches the conversion we are trying.

Anyway, let's see what @Huachao thinks! I think you should open a PR anyway ;)

[cbrevik]

That's a good idea @fmartingr! Probably shouldn't be too much magic, but simple helpers would make things easier.

I wrote this implementation in a hurry, so I'm not satisfied with the solution yet. But I guess I could open a PR if only to discuss approach there.

[akalcik]

@cbrevik I love this idea!

[loverde]

Why not build on the read from a file syntax and support something like this:

POST url/auth
Content-Type: application/json

{...}

> @myToken

And then for referencing variables inside the payload, maybe use JSONPath syntax, e.g.:

{{myToken.value}}
{{myToken.anArray[0]}}

While on the topic, you could also support outputting directly to a file the same way

POST url/auth
Content-Type: application/json

{...}

> ./my_token_file.json

And to use a variable as the output filename:

POST url/auth
Content-Type: application/json

{...}

> {{my_output_filename_variable}}

No matter how it is implemented, this would be a very powerful feature.

[Huachao]

@loverde thanks for your proposal, we already have an implementation in #140 done by @cbrevik and we also have some discussions there and made some agreements there. You can move there, and show your opinion about that.

[oji]

+1 on this, I'd love to see this live!

[Huachao]

With the great help of @cbrevik in #140, this feature will be published in next release. So close for now, more details will be updated in this thread and README. Thank you all for your help in this feature.

[akalcik]

Thank you guys!

[Huachao]

@akalcik @cbrevik @pcornier @joonathan @gianmarcotoso @ndinev @tytodorov @hapylestat @lucsky @narayanan @AnderScore @fmartingr @jgroom33 @aewing @kwellman @oji @pfemiani @loverde @lee-fu you can upgrade to latest version 0.18.0 to use the _request variable_ feature finally, and usage can be found in README. Special thanks for @cbrevik who implemented this feature. And waiting for your feedback.

[jgroom33]

very nice implementation @Huachao @cbrevik