[Feature Request] Allow opening links in response in Insomnia

[SteveMellross]

I prefer Insomnia to Postman in most respects, but one feature I use a lot in Postman, and really miss, is the ability to follow links in the body of one request within Postmman.

I do a lot of work with an API that represents a tree structure with one node per request. The bodies of these requests contain URLs to their child node locations, so the ability to simply click one and have it followed immediately is extremely useful.

When I clink a link in the body of a request in Insomnia, it opens the link in my web browser. If I right click the link I just get an option to copy it. The only way I can see to open it in Insomnia is to copy the link, duplicate the current request (for headers, see below) and paste in the link I want to follow. This is fine to do occasionally, but its very frustrating if you regularly need to follow a lot of links.

For this to be really useful, there needs to be a way to propagate headers (mainly for auth, a custom API key header in our case). Postman handles this by allowing the current requests headers to be copied to the new request of the followed link. Another solution would be to allow setting common headers for a group of requests since not all headers are always required to be copied. I saw something along those lines suggested in another feature request.

I wouldn't want it to follow the link in the current request though. Opening it up in a new request is definitely the way to go. 👍

Thanks!

[welcome]

👋 Thanks for opening your first issue! If you're reporting a 🐞 bug, please make sure
you include steps to reproduce it. If you're requesting a feature 🎁, please provide real
use cases that would benefit. 👪

To help make this a smooth process, please be sure you have first read the
contributing guidelines.

[gschier]

This seems like a great feature to have

[dschulten]

How should the traversal look like? Should it automatically add requests to the list of requests on the left? Or should it happen within the current request context, i.e. by setting a new target URL - if we do that, a Back button would be extremely nice.
Could this be done with a plugin?

[gschier]

I have three potential ideas right now:

• Treat clicked links the same as a redirect
  • append the new request/response to the timeline tab and overwrite the response body/status/time with the new one.
  • would be impossible to go back to and see the original response (could be implemented but would require changing some core behavior)
• Show the new request in an overlay dialog
  • closing the dialog would delete the request
• Append a new response to the current request's history
  • this could be be messy and confusing in my opinion

Could this be done with a plugin?

The plugin system isn't advanced enough to implement a feature like that yet.

[dschulten]

I prefer the first variant, (if I understand it correctly):

• the response to a clicked link would be displayed in the Preview pane
• the raw curl output would be added to the Timeline pane

Can the requests be added to the response history as well?

I found _handleOpenLink in response-viewer.js, I suppose that is where the change has to start from.

Would it be ok for you if I try to load the new link into response viewer and make a pull request? Is there anything I need to be aware of?

[gschier]

For option one it wouldn't be possible to add the response to the history dropdown, since technically it would be the same response.

[gschier]

If you want to play around with a proof of concept that would be alright. I don't think we've settled on a good enough solution yet though.

[dschulten]

If you map this idea to how a browser works, the request definition on the left with the URL address, the body and Auth pane etc. would be an extremely powerful "bookmark editor", whereas the preview pane would be the actual browser window.

[dschulten]

I have created a feature branch in my fork which can follow links in the response view, to experiment with the overall UX and to see if you agree with the concept: https://github.com/dschulten/insomnia/tree/feature/allow-opening-links-in-response

The branch handles clicking on links and creates an in-memory history, with back and forward buttons. This is what it looks like (except for the green triangle in the red box, which I will explain below):

First question: what do you think about the overall UX? Should I open a PR, after adding tests?

Second question:

Currently a click on a link is always a GET. That is not sufficient in many situations. What do you think about the following proposal:
The request in the screenshot is an application/vnd+siren document. I envision a plugin interface which allows plugins for various mediatypes to insert "action" elements into the response, e.g. a green Play triangle in the gutter as shown in the screenshot, and handle click events for those actions.

Example: As you can see, the API in the screenshot contains a Siren form which describes a POST with certain request data (a "hypermedia affordance"). When users click the play triangle alongside the POST action, a Siren plugin could build a request body from the fields description and POST the request. The HAL mediatype has a hal-forms extension which could be used by a HAL plugin, and a HAL plugin could also expand uritemplates with placeholders which may be entered in the dialog. Other media-type specific plugins could offer to enter a method and request body manually, e.g. in a modal request body editor which pops up when the play button is clicked.
Clicking the link would always trigger a GET. Clicking the play button would open a modal popup where plugins can prefill the URL parameters, the method selector and the body.

The job of the plugin would be to deliver three things for the modal:

1. A list of method strings which will be shown as dropdown
2. (opt) Dynamic Markup for input fields, e.g. to prompt for uritemplate vars or field values.
3. (opt) A string with a prefilled request body, for editing by the user.

If you like the latter idea, I could build a separate PR for that.

[gschier]

Nice work on the code @dschulten! I like the direction it's going so far.

First question: what do you think about the overall UX?

I think the UX is off to a good start. I fear it will cause confusion with the history menu on the far right but that's more of a UI/design issue than a UX issue.

How do you feel about adding another horizontal bar (maybe light gray and not that tall) above the tabs to represent the "follow up" responses as breadcrumbs? It would cost a bit more in UI real estate but seems like it could be more clear to the user (just an idea).

You mentioned you're storing the history in memory. I feel like the responses could probably be saved in the DB as children to the original response. This way they would persist across app launches and would probably lead to less bugs.

If you like the latter idea, I could build a separate PR for that.

I think having a plugin API to control link actions may be a good idea for the future but is probably still too undefined to implement at this point. I would prefer to build the general first-party solution first, then go from there using user feedback to drive the roadmap.

✌

[dschulten]

The separate row would have a clear purpose: navigating responses. It could also be used to show clickable links from link headers later.

Should the breadcrumbs replace the back/forward buttons, and what does a breadcrumb item show - maybe the last path segment of the URL, and the query if present, like the network tab in Chrome devtools? Often breadcrumbs represent where you are in the hierarchy, not really a history of movements, but that is not what you had in mind, right? What do we do if the history gets too long to fit, show scroll elements?

One idea I had was to support a long click on back and forward, which could display a list of historic items to choose from.

I'll look into the db. Did you mean to store responses there or requests? From what I saw I gathered that the response bodies are written to the file system in https://github.com/getinsomnia/insomnia/blob/cd4a983d5f41654f27c9c94d6c9d9f3a3e24fa64/packages/insomnia-app/app/network/network.js#L613

[gschier]

and what does a breadcrumb item show

That's what I was thinking but you might be right that it would be too long a lot of the time. The devtools shortening that you mentioned seems like a nice compromise.

Often breadcrumbs represent where you are in the hierarchy, not really a history of movements

This is a good point. I haven't seen breadcrumbs used in this way either. I like the idea of an additional horizontal bar (to differentiate things). Maybe, instead of breadcrumbs, the back/forward arrows could be there and the rest of the space could be filled by the current URL?

One idea I had was to support a long click on back and forward, which could display a list of historic items to choose from.
I think I'd prefer the way browsers do it, which is to right click the back or forward to see the full history.

I'll look into the db. Did you mean to store responses there or requests? From what I saw I gathered that the response bodies are written to the file system in

Correct, response bodies are stored to disk automatically. However, the actual response object needs to be saved to the local DB too. You can see where this happens for normal requests in app.js. All DB models also have a parentId property which points to their parent. Normal responses have parentId = request._id. For "follow-up" responses, I suggest setting parentId = firstResponse._id. I'm probably doing a bad job at explaining this. Feel free to leave this part 'till later and I can help out or you can pass the remaining work to me.

https://github.com/getinsomnia/insomnia/blob/cd4a983d5f41654f27c9c94d6c9d9f3a3e24fa64/packages/insomnia-app/app/ui/containers/app.js#L454-L495

[stdedos]

I am not good at explaining (or visualizing) ideas. I will try, however, because current workflow for me is exhaustive (and drives me away from an otherwise really well-thought program).

---

Prelude

So far how the system is laid out to me, is that I have multiple MRU links/requests, and then I approach "actions" I'd like to execute / test / explore.

---

Currently, my only possible way of working is if I generate a "template" request, and then have a buffer of
"(Copy) (Copy)" items for all the mundane tasks that I do (or follow-up href's that come).

Also, the only fast way to follow urls, is if I open then, F6; Ctrl+A the url, and return it in "another" "(Copy) (Copy) (Copy)" item. Fine-selecting a url with small font in a 4K screen is an annoying task. You cannot even Right-Click -> Copy URL in the preview.

---

I would imagine that my flow would go a bit like this:

1. Click on an Template
2. Optionally, edit it (e.g. if it's a search template)
3. Execute Query.

Then the program would, in a tree-like fashion:

1. Create a child under that template
2. Would add all the differences from the template (e.g. Called timestamp, GET changed to POST, part of a URL was changed (or it could be a placeholder was given value).

Then, if you e.g. follow a url from the response:

1. Create a child under the aforementioned child
2. Add a note of the url clicked.

And continue as such.

It feels as this is somewhat-related to #447

---

This could all be searchable from a "free form search box". This mean it would also make it easier to have Back/Forward visualization, it could also show workflows of a specific process (e.g. "useful trees" could be marked with a 'green checkmark' which would only show checkmarked items and the "WIP" tree that has derived during that part)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bradjones1]

Unstale

[gschier]

Sorry, Stalebot was acting up since I change some of the label names!

[dschulten]

In https://github.com/dschulten/insomnia/tree/feature/allow-opening-links-in-response I have prepared a feature branch where you could try out the current mechanism. It is very simple:

• Clicking links will follow them
• You get a history with back/forward buttons and a current address
• The history is stored together with the request definition
• If a response is the result of a redirect, the history stores the redirect target to support the post-redirect-get pattern

If that is useful, I can make it a PR

[skyhirider]

How is this looking? Seems like a nice feature to add as even right clicking on a link does not allow us to copy it, so we either must drag and copy, or click, open in browser then select and copy.

[stdedos]

Seems stale both ways to me. I don't think it received a proper review, and there are some things in the air from owner's point of view.

Honestly, I think @dschulten has had a pretty good idea of what everyone in this thread is requesting (and it is implemented), but the code needs to go through a quality gate.

[mwmcode]

Hello,

Is this still planned?

[mick-net]

Hello,

Is this still planned?

+1. Recently moved from Postman to Insomnia, but still missing this feature in Insomnia to open a URL from a (JSON) response as a new (temporarily) request.

[DaisyCutter]

+1 This would be super helpful for my environments.