-
Notifications
You must be signed in to change notification settings - Fork 1.9k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Parent Requests #447
Comments
Please leave comments here with any feedback you may have! 😄 👍 |
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 ;) 👍 |
@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 |
So it's more like an inherited request so we can say than selected request extends specified request, right? Maybe a template request? To-do list as I see it:
So, what do you think? |
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 As for the implementation. I think that if we had an Things to note:
|
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:
|
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. |
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. |
Hi! To jump in this discussion: I don't think the notion that you can do this by minimal UI changes is a viable one.
I hope you will agree with me or tell me where I' wrong. |
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). |
@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 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. |
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. |
I'm very interested ;) |
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: #598 |
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. |
@woodj22, you may find this plugin useful: https://github.com/getinsomnia/insomnia/tree/master/plugins/insomnia-plugin-default-headers |
@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. |
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. |
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)? |
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. |
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. |
@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 |
@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 |
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. |
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. |
@goddard82 you can do that already with https://support.insomnia.rest/article/43-chaining-requests |
@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. |
So any status on this? |
Also, the insomnia-plugin-default-headers is not working, maybe it's me but I followed the guide |
Forget that last comment, made a simple mistake, forgot the Bearer part 😂 |
Would also love a status on this. |
I needed this for my use case, so I went along and created it: https://www.npmjs.com/package/insomnia-plugin-default-queries |
It would be SO GREAT if we had this!! |
Just found this and noticed it's been a few years since we've heard anything. I'd have to say this would probably be the best thing to come to Insomnia since sliced bread for me. Any updates on when this might roll out? |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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...
Potential Problems
This feature isn't perfect, of course. Here are some problems that may arise.
A
,B
,C
and want to set authentication forA
andB
and set default headers forB
andC
, a parent request would not work. Perhaps this is a necessary trade-off?The text was updated successfully, but these errors were encountered: