Parent Requests

[gschier]

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:

1. The UI needed to assign and show parent requests. This will likely be done from the sidebar.
2. The UI needed when editing a request to show inherited properties as read-only. For example, a header that is inherited from a parent would be displayed in a disabled state with a note saying where it was inherited from.

To-Do

• Write merging algorithm w/ tests
• Find way to represent the diff between the final request and original so we can show parent attributes in the UI
• Show extended parent attributes in request editor pane
• Figure out how to assign parents to requests
• Build UI for parent request assignment
• Update code to take parent requests into account
  • Sending requests
  • Generating code
  • Workspace export (should this export merged requests or include parents in the export?)
  • HAR export
• Beta release and testing/feedback
• ...?

Questions

• How should a parent-child relationship be defined? Should parent be specified from the request (up) or from the folder/workspace (down). Or both?
• How to merge key/value pairs with duplicate names?
  • Headers, query params, and form data are allowed to have duplicated field names. I'm thinking it's more common to replace a field from the child then append a duplicate. Thoughts?
• Should it be possible to inherit ____? If so, how?
  • URL
  • HTTP Method
  • Settings

Screenshots

Please look at the Questions above and leave your feedback!

[partty]

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 can't see any upside for the top down approach! choosing a parent request from the child seems like the only option. However, for convenience, in the side bar, you can have an option like "Create child request".
• The merger seams like a hard problem, you can have use cases for both. So maybe you should ask where will the setting go? In my mind it makes more sense that the user should be in control from the child request.
  How about letting the child add duplicates and indicating with some color that the field is present in the inherited fields. If the user needs to overwrite it, he should be able to turn off the parent field manually.
• Why not inherit everything? I understand the URL and HTTP method will be overwritten most of the time, but if it is not so much of a hustle, maybe inheriting them will help people. However, inheriting them doesn't seem very useful for me.

I plan to take a look at the code soon, so maybe I can be more help in the future :)

[gschier]

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:

• Have the ability to assign a parent request from the request dropdown in the sidebar (or maybe from the request setting dialog?)
• If no parent request is defined, use the "default"
• Have an option on the workspace to set a "default" parent request
• The "default" parent request will be overridden if a different one (not the default) is chosen for a given request

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 __PARENT__ if one exists.

[gschier]

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.

[partty]

@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.
Also, what happens if you change the default parent request "A" with the parent request "B"? Do all the children switch to using B? Or just the new requests created from now on will use B?
Maybe a dialog for the user to choose what to do?

Let me repeat an idea from the other discussion:
"Copy as parent" on the parent and then "paste parent" multiple times on every child request you need to inherit it.
It's a simple way to disregard any preferences for an inheritance model, as with a keyboard shortcuts for this will be really fast for users to do. Faster than any other interface solution as you can do this focused only on in the left menu.
Do you think this is feasible for now, or it'll be too complicated?

[gschier]

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.

[partty]

@gschier maybe I'm missing something, but I don't see your point about the multiple active environments.
As far as I know multiple active environments won't solve anything for me. (but still a good feature to have!)

Parent requests being too general...
Yes, they are! That's why I think, multiple levels of inheritance is required to achieve full functionality. One parent will give the authentication and the other headers. However this is becoming complicated, and will require more from the UI.

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?
To me such "smart" vars will solve all issues I can imagine with reusing stuff.

[gschier]

@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 😄

[partty]

@gschier I intentionally don't give more details. I assume that my use of insomnia is a bit different from most others.
However, because you asked:
So I create a workspace for the project. This project includes multiple different APIs with different rules and requirements. Different users pools too.
As I develop the API I control both sides, so I use Insomnia to check my functionality while developing. The users in both pools can be the same, but I keep them different, so if the wrong user can get access to the wrong API I can catch it early.
I include the workspace export in the project's repository, so my colleagues and the QAs can get up and running fast. As you can imagine, I use an environment vars for URL and USER and PASS, so I can switch between installs, and so the colleagues can change this settings for them after importing the workspace.
Although I have different requests set up in insomnia for the different APIs in his project I use the same environment vars for user, pass, url. And I switch between different types of users with the environment. This is intentional, as I mentioned I need to test the wrong users on the wrong API.

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.
My trouble is with the preview mods, this is something I'd like to be able to change quickly (I've written a feature request about it #585)

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.

[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.

[svpace]

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:

• How should a parent-child relationship be defined?
  Folders, as it is now
• How to merge key/value pairs with duplicate names?
  Child (request or folder) replace parent value
• Should it be possible to inherit ____? If so, how?
  • URL
    Yes. As a base URL for the child requests. Child requests would provide absolute or relative URLs
  • HTTP Method
    No. I really can't think of a reasonable use case for this
  • Settings
    Yes

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 :)