[Feat Request] - Chaining request

[kobenguyent]

Hi, I'm coming from the Insomnia world, there is one very useful feat that I'd love to see is https://docs.insomnia.rest/insomnia/chaining-requests. May I know if that would be added in the near future?

Thanks!

[flawiddsouza]

Would love to add it. Seems a bit complex to implement. Will look into it.

[bjsvedin]

I am going to second this request. I have been using the deprecated no longer supported Insomnium all year, and I can't move away from it without being able to pull values from the response of another request. Restfox has everything I need EXCEPT this. I have searched every other rest client out there and none of them support this feature. My reasoning for wanting this feature is to handle my authentication flows without storing anything sensitive in environment variables that can end up in the git repo. Responses are ignored by default which is great, so pulling sensitive access tokens from the response directly rather than storing it in the environment has been a life saver with Insomnium. If you have a work around for this problem right now please let me know and I'll move to Restfox

[flawiddsouza]

Hi @bjsvedin, currently there's no workaround. I'll prioritize this for the coming weeks. Will work on this when I get some time.

[flawiddsouza]

Hi, response tag is now implemented that allows you to do the same thing as insomnia:

You can test it at https://restfox.dev.

Will be released for desktop in a day or two.

[kobenguyent]

Thanks for bringing this feat to life. I have some concerns:

• is it by default to always show Response Tag hint next to the function?
  
• when I have only one response, I see nothing in the select list, is it also by design?
  
• removing all the response filter doesn't give back the response value just []
  

[flawiddsouza]

I just added Response Tag as description because I didn't know what else to add there. We can update this, if you have a good description.

I don't think there's any other way one can handle this, so I'm not sure what exactly the concern is here. There are no requests, hence the dropdown is empty. Seems reasonable. Let me know what is your expected behavior and I'll see if I can implement that.

This is because empty JSONPath results in 0 matches on body, hence you get []. To get the full body, you can use:

The only reason you get full body in the response panel is because we treat absent of jsonpath as no jsonpath being active and show the full response. In JSONPath, you need to pass $ to get the full body:

[kobenguyent]

1. Well, this is how Insomnia is displaying it. imho, it looks better without the tag there.
   

2. Sorry, I didn't convey it well, I mean I had one request in my collection, so would be a really rare case as I think there is no collection with only one request.

3. I would expect when we remove the filter, the full response would be showing.

[flawiddsouza]

1. Sounds good. I'll remove the description.
2. Do you want me to change anything here?
3. Then I'll update it, so we get the full response when jsonpath is empty.

[kobenguyent]

2. I would Imagine you still see the list of request eventhou I have only one request in my Collection.

[flawiddsouza]

2. The request list will never show the request you're currently in. As a request cannot reference itself. If there was only one request in the collection, that's the reason the request list is empty.

[kobenguyent]

Thanks for the reply! Then maybe we could add a hint or something so that user knows okay, that's normal behavior.

[bjsvedin]

Wow! I wasn't expecting you to outright lift the insomnia UI for this, so I am pleasantly surprised. I was expecting the functionality to be added into the script portion of the app. I would have been happy either way. I will give this some tests and set it up in my work flow.

[bjsvedin]

I have a few bugs/suggestions to report.

Bug 1:

When you use attribute body and need to wrap the resulting value is quotes this messes up the highlighting for the text following it.

Bug 2:

It is possible to insert a response tag and not get the UI button over it, rather it leaves the raw placeholder. This can easily be achieved if there are empty opening and closing placeholder characters.

Suggestion 1:
Allow response tags as an environment variable.

Suggestion 2:
Since this pattern is lifted directly out of Insomnia, can you support importing existing response tags from an insomnia json file?

[flawiddsouza]

Bug 1: Might be in the same category as #228, so not sure if we can actually fix it without implementing custom syntax highlighting for JSON.

Bug 2: I've pushed some fixes. They're deployed at: https://restfox.dev. Can you check and let me know if they're now resolved?

Suggestion 1: Do you mean, you want to be able to use response tags in environment here?

Suggestion 2: Sounds like a good idea. Even though it looks the same as insomnia, it's not really the same.
Insomnia: {% response('123', 'body', ...) %}
Restfox: {% response(id='123', attribute='body', ...) %}

[bjsvedin]

Yes. For Suggestion 1 that is what I mean by using a response tag as an environment variable.

[bjsvedin]

I just tested out the the fix for bug 2, I am not able to recreate it anymore, but it seems another thing broke at the same time.

Clicking save does in the responseTag dialog does not close it anymore. It does save, if i then click the X button to close it, then reopen it, the data will still be there. But if I try so send a request i get the error

Error: Could not resolve tag
response()
at ━>response(...)<━

[flawiddsouza]

Clicking save does in the responseTag dialog does not close it anymore. It does save, if i then click the X button to close it, then reopen it, the data will still be there. But if I try so send a request i get the error

I'm not able to recreate this issue. I can click save and it closes the dialog. Can you check the chrome devtools console using Ctrl + Shift + i to see if there's any error?

Also, clicking on x will never save the data. When you reopen the tag, it should have original data itself.

If possible, can you export the restfox workspace and attach it here, so I can check.

[bjsvedin]

Nvm, I don't have the issue anymore. I think it was a caching issue. I thought I had hard refreshed the page since the last time I used it, but maybe I didn't.