Insomnia: [Feature] Parent Requests

[gschier]

Why

Ever since launching Insomnia over a year ago, I've received many questions asking "How can I set X for every request", with the most common values for X being headers (#266) and authentication (#330). I knew that eventually I wanted Insomnia to be able to do these things, but was never happy with adding a one-off feature for each, complicating the user experience and forcing the user to learn more things.

What

Parent Requests (TODO: think of a better name) is a single feature meant to solve the above problem for every possible value of X, by allowing the user to define a request that can be inherited by other requests in a simple and intuitive way.

Parent requests...

• look similar to a normal request, except that they cannot be sent
  
  
  
  • doesn't require learning anything new
  
  
• child requests will show overridden attributes as read-only
• list attributes (headers, etc) will be merged (based on name) instead of completely overridden
• will be prominently displayed in the sidebar (not sure how yet)

Potential Problems

This feature isn't perfect, of course. Here are some problems that may arise.

• If we have requests A, B, C and want to set authentication for A and B and set default headers for B and C, a parent request would not work. Perhaps this is a necessary trade-off?
• This feature imposes a certain folder structure, which may come in conflict with common organization strategies. For example, if API requests are grouped by resource and you want a certain set of requests to share a comment authentication scheme. A way to solve this could be to have a request define its parent, rather than the other way around.

[gschier]

Please leave comments here with any feedback you may have! 😄 👍

[Andacious]

So when a child request is made, Insomnia will automatically send the parent request before sending the child request? This is an oversimplification, but I want to make sure I understand the scenario. It gets really interesting if you allow a parent request to have a parent request....that would essentially unlock true automated request chaining, which would also be a neat feature ;) 👍

[gschier]

@Andacious not quite. What you describe (chaining) already partially exists as a feature: https://insomnia.rest/documentation/request-chaining/

This feature would strictly be about inheritance (think of inheritance in object oriented programming). The parent request is never sent, but only used to populate fields on its children. For example, if a parent request had a Cookie: foo=bar header, all children would, by default, inherit that header. That way, you wouldn't have to manually add it to each one.

[ValeriaVG]

So it's more like an inherited request so we can say than selected request extends specified request, right? Maybe a template request?
I'd like to help with it, seems to be a great improvement.

To-do list as I see it:

• Figure out what will it be: A normal request (so existing ones can be used) or a separate type with the ability to create it from a normal request
• Figure out how it will look like and/or where it will be rendered/controlled (new settings tab, same as request, but with a mark)
• Figure out how the assignment of the "template" will look like: Can it be assigned to existing requests or only new ones can be created with it?
• The implementation itself

So, what do you think?

[gschier]

Yes, exactly @ValeriaVG.

Sorry for the delay. I'm moving at the end of the month so am quite busy.

I'd like to get started on this soon and would love your help if you're interested.

I think parent requests could reuse the same data model as a normal request, but include an extra property to distinguish it like isParent: true. This would make it very easy to convert requests to parent requests and vice-versa.

As for the implementation. I think that if we had an extend(request, parentRequest) function that knows how to merge two requests together, it would get us most of the way there. Then, during the render stage, we can find all parent requests and merge each one to get the final output. At that point, we can then use the final request the same way we do now.

Things to note:

• It would be nice if the merge function listed the paths of all the fields it filled in. This would let us show the inherited values in the UI while editing a request.
• The HTTP method is the only field that doesn't have an empty state? Should we add a new HTTP method "UNSET" in order to allow the request to default to the parent's method?
• I think the parent request UI could probably be the exact same as the normal request UI, but remove the response panel.

[ValeriaVG]

Totally understand your situation, @gschier . Going to opposite part of the globe in less than a month myself=) So if you need some help with other high priority issues let me know, I'll do my best.

Back to the parent request. For now I have some questions:

• Will add isParent to the settings panel?
• How will we visually separate parent requests from common ones (icon, separate group etc)?
• How can the user test the request if he cannot run it? Through switching to common request and back?
• Why do we need to separate parent requests? Isn't it better to add parent field to the request in this case? We also can add a link to the "parent" from a "child" request's view
• I assume request will inherit properties dynamically? Or only upon creation?

[meagerman]

I think it would be obscure and tedious to have to specify the parent for each child request in an ad-hoc way. Instead, I think folders are ideally placed to become parent requests.

This would allow you to set properties for whole groups of requests. Yes, it may not be use-able for some existing organizational structures, but clearly requests in the same folder share something otherwise they would not be in a folder together.

This would also solve the problem of how to represent the parent request in the UI. It would be a natural way to visualize your inheritance structure.

Folders currently only visually group requests together, as well as defining a new environment (that overrides the global environment) and I think this feature would give the folder feature some real meat.

[stale[bot]]

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.

[partty]

Hi! To jump in this discussion:
Folders are fine to represent parent request for small projects, but I think there is an issue with having a set of parent requests, that every other requests extend.
Consider this example: You have a REST API that exposes resources and you are creating a set of requests for every resource. Maybe you want to have a parent request that all the "list-getters" extend and another one that all the "creators" extend, but if you are organizing by resource, you wouldn't be able to do that with folders being the parent request.

I don't think the notion that you can do this by minimal UI changes is a viable one.

• I think that you should set a parent request from within the child request!
• I believe that seeing the inherited values is essential.
• When the user is looking at a child request he should see a rendition of what the request will be like, but that rendition shouldn't be evaluated yet. So if the parent request includes variables, they should be displayed as such.
• I think once you see the inherited values you should be able to exclude one of the parameters or one of the headers, without replacing it or all of them. (this will be hard to do, but will add to the usability of the feature)
• Choosing the children from the parent request may be useful, but it'll add more changes to the UI.
• For representation I think that if all requests may be parents or children it'll be most useful. And maybe you just ad some tag or pictogram to indicate if a request "is a child" (has parent/is dependent on another request). Like this will indicate not a virtual status of the request, but that the request is not stand alone request and it needs something else to work.
• Yes, this feature will solve the problem with the authentication not being reusable!

I hope you will agree with me or tell me where I' wrong.

[gschier]

Thanks for the great feedback @partty! I agree mostly with all of your points, but I'm still undecided whether a parent-child or child-parent model is better.

Right now, I'm leaning towards setting the parent from the child because it solves every use case. Then, if users find that it's too much work to set that up, other improvements could be made on top of that to make the process easier (bulk editing, etc).

[partty]

@gschier I see that setting hundreds of requests can be a pain, but you should really think in terms of "What's the difference for the user" and "is this saving any time event with the most basic implementation"
So right now I make a copy of a request and change 2-3 things to create a new one. But if something that I've copied needs to change... it's a massive pain!
If this feature is implemented, it will save time with changing copied stuff and mostly the authentication.
So I don't think it's a more hustle than the copying requests and changing values.
The only trouble is that if i want to update my current workspace it will be a bit slow, but hey, the old requests won't stop working, so updating them is optional.

So I don't see any downsides! I see only benefits!

One idea is to use a context menu and have an option like "create child request" to speed up the inheritance for new requests.
In that frame of thinking you can have a "copy as parent" and "paste as parent" options too.
I suppose any of that stuff has no real impact for the architecture of this feature ;)

[gschier]

Yes, great point. It will still be much better than the current workflow.

P.S. I plan to start working on this soon. I'm thinking of putting this, along with a few other features, into a 6.0 release. Since the changes are fairly large I'll probably do a beta testing period so let me know if you are interested in trying it out.

[partty]

I'm very interested ;)

[gschier]

I just started working on a PR for this feature and have posted a number of open questions. If you have a few minutes, please post any feedback or suggestions you have: https://github.com/getinsomnia/insomnia/pull/598

[gschier]

Just a little teaser on what the UI will look like when a request extends a parent request.

[woodj22]

Very nice. This will save me so much time. I use custom headers in a lot of middleware so it would be great to be able to turn it off and on at a click of a button to test the different responses defined by different middleware request lifecycles.

For my own understanding and learning I have a question:

_Why can their not be a section in the environment variables which represents global headers/queries as JSON?_

I know it complicates the user experience a little as stated in the description but i think it 'fees' like the right place as each header does belong to an environment.

However, I do get that making the environments menu and JSON more complicated will take away from its wonderful, easy and nice to use experience.

[gschier]

@woodj22, you may find this plugin useful: https://github.com/getinsomnia/insomnia/tree/master/plugins/insomnia-plugin-default-headers

[woodj22]

@gschier oooo very nice. Do plugins ever go into the full on program? I suppose their is no point as people can pick and choose what they want.

Thanks for the help.

[gschier]

If popular enough than I don't see why not. The long-term plan is to pull as much out as possible into plugins but then have a core set that get included by default with the app – similar to how Atom works.

[SylwesterZarebski]

Name proposal: Abstract request for non sendable base requests. Template request mentioned above is also nice.

But maybe it will be simpler to have plain inheritance (chaining) between any requests (only catch: check for loops)?

[afeblot]

I thought the default header plugin was enough for my globally defined authentication, until this morning, I had to deal with Oauth2. I manually got my token generated and added the "authorization: Bearer xxxxxx" global header. Which worked for 30 minutes until the token expired. I don't see myself manually generating a new token every 30 minutes, so I'd like to use the Oauth2 Auth supported by Insomnia. Which can't so far be defined globally.

[stepjanssen]

This would be great to have. One case is that one of the applications I'm working wtih returns xml by default, so on every request I need to add a parameter to get a json response. It would be really conveniet if I only had to do this once.

[gschier]

@stepjanssen is the parameter you need to pass a header? If so, you can use this plugin: https://www.npmjs.com/package/insomnia-plugin-default-headers

[stepjanssen]

@gschier, unfortunately, no. I need to pass these parameters in the query string.

[gschier]

It would be easy to alter that plugin to work with query parameters instead of headers

[bugproof]

It would be nice if there was some kind of inheritance, even something like folder-based settings, so you set, for example, bearer per folder and all the requests inside that folder inherit it by default.

[goddard82]

I would like to be able to add chained responses (e.g. a user token and a session token from the response header of a login request) to the default headers of other requests, so I can login once, then all other requests are ready to go without having to set up theses token values in the default headers manually.

[gschier]

@goddard82 you can do that already with https://support.insomnia.rest/article/43-chaining-requests

[goddard82]

@gschier It won't work when I'm trying to add token info into default headers, it says there is no header filter specified and I get an error such as "Unexpected token { in JSON in position 157". I saw on another thread something about it not working due to being unable to set nested values (such as default headers).

edit I solved this by placing the resp.headers variable in quotes in the environmental variables default headers and it works.

[ThaDaVos]

So any status on this?
Currently moving from Postman to Insomnia and this is the only thing missing - currently going to use https://www.npmjs.com/package/insomnia-plugin-default-headers for the headers but would love the idea of the template requests and not be restricted to folders like in Postman

[ThaDaVos]

Also, the insomnia-plugin-default-headers is not working, maybe it's me but I followed the guide

[ThaDaVos]

Forget that last comment, made a simple mistake, forgot the Bearer part 😂

[mattsson]

Would also love a status on this.

[andreduvoisin]

@gschier, unfortunately, no. I need to pass these parameters in the query string.

It would be easy to alter that plugin to work with query parameters instead of headers

I needed this for my use case, so I went along and created it: https://www.npmjs.com/package/insomnia-plugin-default-queries

[tberne]

It would be SO GREAT if we had this!!