-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Parent Requests #598
Parent Requests #598
Conversation
7c47cdb
to
399ad75
Compare
399ad75
to
e45d7cc
Compare
76f87ac
to
9f1d8a5
Compare
Let me give you one more question to ponder: Do you allow only one level of inheritance or you can inherit multiple levels like the OOP classes? And then, do you inherit only one request like the class extends, or you can inherit an arbitrary number of unrelated requests? I'm thinking that over complicating things is bad! So I'm suggesting the one level inheritance, and inheriting from only one parent! On the screenshots you are using the word "parent headers", I'll suggest to change it to "inherited headers". Or you can add the name of the request? For the questions:
I plan to take a look at the code soon, so maybe I can be more help in the future :) |
Great question @partty. I think one level of inheritance to start is fine but I can definitely see users asking for it. Overall, I agree that simple is better. To respond to your first point. One of the most common use-cases for this feature is defining default headers and/or authentication for an entire workspace. I think that is a strong case for the top-down inheritance approach. Here is what I'm picturing at the moment:
As for URL, I currently have it set up to inherit the parent URL if it is empty. And, the UI will even show the parent URL as the placeholder on the field. As for the method, the reason this is hard is because there is no way to have an "unset" method. Since children always have a method defined, they will never inherit. One way around this would be to add an additional "unset" method, but I think that's too complicated. Also, feel free to pull down this branch and try it out. Right now I have it hacked to have all requests automatically inherit from a request with the name |
Also, I agree that "parent headers" would be better described as "inherited headers". I also plan to put a link to the parent request beside that heading when possible. |
…feature/parent-requests
@gschier I can see your point for the top down. However the way I use Insomnia is to have one workspace per project, but most of my projects have multiple interfaces with different user pools and different rules. That's way I can't see the use of default parent request. Let me repeat an idea from the other discussion: |
…feature/parent-requests
After thinking about this for a few days, I think that maybe parent requests is too generic of a solution to be useful. For your needs @partty, I have a feeling that Multiple Active Environments (#283) could solve your problems. However, I'd be curious to hear what your use-cases actually are in detail. The two main use cases that prompted this feature were the ability to re-use authentication and headers across many requests. Parent requests are actually not a great solution for this because once you inherit a request, you get both the headers and the auth. There is no fine-grained control to select just the headers, just the auth, or both. I think I'm going to sit on this one for a while and tackle #283 first. Maybe that will cover enough use-cases to make parent requests a moot point. |
@gschier maybe I'm missing something, but I don't see your point about the multiple active environments. Parent requests being too general... Ok if the main thing being solved is reusing authentication and headers, haw about environment variable that can hold an Authentication object and another one that can hold a headers string or list of headers? |
@partty, I was just guessing at your use case so I could be completely off. Since you mentioned multiple users pools I assumed it would fit well. For example, you could have both a Production and UserA environment active at the same time. If you could describe what your current workflow is that would help a lot 👍 I'd like to clarify the "too general" statement as well. I think that being general is great for a feature, meaning it can be used to solve many different problems. However, I think parent requests are general in a bad way. A lot of the things parent requests solve can also be solved in other ways and parent requests don't seem to solve anything really well. Like you said, multiple inheritance would be required to make the feature useful but I can see that being overly complex and confusing. As for setting headers with "smart variables", I wrote a small plugin to accomplish that: https://www.npmjs.com/package/insomnia-plugin-default-headers. The same thing could be done for auth too. Maybe that's enough for now? Again, I'd love to hear more about your workflow in case I'm missing something 😄 |
@gschier I intentionally don't give more details. I assume that my use of insomnia is a bit different from most others. In my day to day only the headers and authentications are painful to copy, so I just clone the requests and then change them. I spend some time on every request while developing the API. I care little about making the requests quickly. I'm organising my request by 'Interface' first, then 'resource', then 'request types'. Sometimes there is a 'module' categorization too... Sometimes I have collection requests, that are pretty complicated and I would like to have some top level parent request, so I can use it in multiple interfaces and resources to make my life easier when there are general changes. I hope this gives you more of an idea how I use Insomnia! PS: I started looking at the code, and for now I'm still lost in the react stuff. I believe I found a bit of a hack to inherit authentications, as a separate authentication method called "inherit". But I'm still struggling to show a dropdown in the Auth editor. So "to be continued" on that. |
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, Sorry to resurrect this topic. I am a "newish" Insomnia user (thanks for the great work by the way) and I believe that this feature would really useful. IMHO the folders are the natural element for such feature. In fact my first reaction when a needed to "share" authentication between requests was to right-click on the folder containing the requests. When selected folders should present the exact same interface as requests, including the send button, which would allow me to send every request in the folder as suggested in #1539. My 2 cents:
Again, IMHO, this feature most likely will not cover any and all reuse use-case in the book, but it fits well in the current user interface, reuses the current request look and feel and would probably cover a lot of common uses. Thanks again for this wonderful tool and I hope we can recover that "parent-request" branch :) |
this PR is currently on hold. See #598 (comment) for reason
Closes #447
This PR implements parent requests. So far I'm just playing around with the merging algorithm trying to figure out the most intuitive way to merge each request attribute. This process has raised a bunch of questions so Please look at the Questions section below and leave your feedback.
What are Parent Requests
If you are familiar with object oriented programming, parent request should be a familiar concept. Essentially, this feature provides the ability to have one request inherit default properties from another request (the parent). For example, a parent request might define a header of
Accept: application/json
which would automatically get added to each child that inherits that it.User Experience
The user experience for this feature can be divided into two parts:
To-Do
Questions
Screenshots
Please look at the Questions above and leave your feedback!