[Feature Request] Temporary Tabs, don't auto save

[BrendanBall]

• Insomnia Version: latest
• Operating System: All

Details

Basically, the postman workflow works well for me. workflows:

1. Create new tab, do stuff, maybe save to collection, maybe discard.
2. Open saved request, edit stuff like resource id or body, run request, discard changes ie. close tab without saving. workflow 1. is mainly for ad hoc stuff. I don't want a long lived request for every single request I want to make. It's much easier to close temporary tabs with Ctrl+w than manually doing multiple mouse clicks to delete a request in insomnia. workflow 2. is used a lot seen as I have many predefined collections. The current workflow of auto saving every change you make to the request doesn't work for me as my predefined collections will become very messy over time. I often open 5+ requests from a collection, change a resource id or data, use the requests, then close all those tabs by mashing Ctrl+w so that my collections are back to their pristine state.

This is basically whats preventing me from moving over from postman to insomnia. The last time I had a look at insomnia I gave up after realising this lack of feature in insomnia, but I recently found out insomnia has graphql support (minus the schema explorer which everyone still wants) which is making me look at insomnia again. IMHO temporary tabs and no auto saving are even more important features when it comes to graphql seen as you often mess around with the queries a lot more.

From the looks of it, I can see insomnia pretty much cannot support this, but I'd really like to see what other people think of this. Maybe even just disabling auto saving and not adding tabs might be good enough.

It would be really awesome if I can use one app for both rest and graphql.

[welcome[bot]]

👋 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]

I'm happy to discuss this. I think we should probably refrain from talking about autosaving specifically, since it's very core to how Insomnia works. However, there might be some less-intrusive additions we could make to support the workflows you mentioned.

I will start it off by saying that, while I like the autosave feature a lot, I do occasionally wish I could revert to back to the "predefined" request after playing around. Sometimes I'll make a change and realize I can't get back to the original.

Here are some ideas for more lightweight additions that may help:

Request Version History (easiest solution)

A similar tool that comes to mind is Google Docs. It also has autosave but it surfaces a version history, making it easy to revert changes if/when needed. Insomnia already saves a request version history (for use with the response history feature) but there is currently no way for users to access it directly.

Request/Folder Locking or Snapshots

Another option, which may also provide additional benefits, is to implement snapshots. Essentially, a folder or request could be snapshotted to a specific version. I imagine some sort of indicator showing up in the sidebar after modifications are made that allow you to easily revert to the locked version, or commit the changes to the shapshot. This is essentially equivalent to disabling autosave but complements Insomnia's current workflow instead of changes it.

Note: this may be technically challenging to implement because we (probably?) wouldn't want changes to the snapshot to be picked up by the sync system. For this to work, they would need to be saved as separate requests under the hood. (See next feature for an easier-to-implement alternative to this.)

Scratch Requests

The JetBrains IDEs also autosave files and don't allow unsaved files to be edited. However, they provide the concept of "scratch files" that can be created by the user. These files don't exist as part of the project and I think disappear after a while. Scratch files can be accessed in the project explorer in a separate section from the project files. I can see this also being combined with file locking by starting a new "scratch" when attempting to edit a locked file.

[BrendanBall]

I'm glad that you've already thought about this and have solutions that fit insomnia.

I like the combination of locking/snapshots and scratch requests. The scratches might be useful if you want to branch edits of a saved request concurrently, ie. open the same request in 2 different tabs and make different changes in each. As long as that scratch still references its parent as the saved request so that you can optionally update the snapshot from a edited scratch.

Which technology are you currently using for the version history?

[Gabb1995]

I think the scratch file idea would work fine with Insomnia, right-clicking a request and having an option to create scratch file from a request.

Scratch files would be temporary and deleted after the current session is closed?

[PrgSkidmark]

I still want the ability to have all the calls saved with names to make specific tests. I currently have duplicated requests named with what it does with different bodies: Transaction_Insert (Case 1) Transaction_Insert (Case 2) Transaction_Insert (Case 3)

If I tested Case 1 with a scratch file and it disappears automatically then I'll have to waste time recreating. It probably should stay until closing is desired. A copy could be saved in temp storage and retrieved later if desired like RedGate SSMS Tab History. A named scratch file would be good.

A request version history would be like having one Request but with a list of past requests that would require I hunt through the requests until I find Case 1 right?

I think that a Request with some collection of bodies that can be named would be more beneficial. The body can have short lives, or be saved, or dated with versions.

[gschier]

scratch file and it disappears automatically then I'll have to waste time recreating

I think it makes sense for scratch request to remain indefinitely, until deletion is desired (like you said).

A request version history would be like having one Request but with a list of past requests that would require I hunt through the requests until I find Case 1 right?

Correct. This would be more useful for simple reversions if a change was accidentally made.

I think that a Request with some collection of bodies that can be named would be more beneficial.

This is tricky because your point could be applied to any request property (query, auth, headers, etc). I think named scratches would potentially work for this. However, I was imagining scratch requests being lumped together at the bottom of the sidebar, without folders. It sounds like what you want would be for scratch files to live more closely to the original requests. I think I agree here actually.

What if scratch requests were considered more like branches or forks? You could fork a request (locked or not) and give it a name. Then there could be an easy way to switch between forks of an individual request (or folder).

[gschier]

@BrendanBall I should have replied to you first, sorry. Yes, I think the concept of branched edits is awesome!

Which technology are you currently using for the version history?

No technology. Every version is just a duplicate of the request object. You can see the code here https://github.com/getinsomnia/insomnia/blob/develop/packages/insomnia-app/app/models/request-version.js

[gschier]

Scratch files would be temporary and deleted after the current session is closed?

@Gabb1995 as discussed, I think they would stick around forever but there should probably be an easy way to clear them out if needed (I think?)

[PrgSkidmark]

Branches and leaves would work for me and you say they’ll have a name. I create duplicate requests named with different parameters, or bodies, and then those parameters have different values. If the main request was branched, and branch A had set of parameters or body A, or perhaps headers etc., then each request with necessary different values, leaves, are nested in that branch. If a condition might need satisfied because scope creep then branch B can be made with a set of parameters or body B. Then all the leaves with different values are under that.

I guess the trunk request has some shared things with the branch and leaves to make it necessary in a specific workflow scenario for someone right?

If any of these are “temporary” for whatever reason can there be some extra indicator like a little color dot like the environment to mark the testing ones versus the good ones to keep?

[natebrunette]

I would primarily use this feature as a place to paste ad-hoc curl requests. It would be convenient for me if the new tabs defaulted to not using an environment. Perhaps unless it was created by duplicating a request?

[hollesse]

@gschier I would like to use insomnia in our company. At the moment we are using postman. Insomnia have a lot of benefits but also one big disadvantage and thats the autosaving. In our Postman collection that we share we have a some requests for our different services, but the most time we test some special cases where we have to edit the request. Therefore i now have to duplicate a request to change some parameters. But after that i have to delete the request. For that reason Postman is more comfortable because there we can change the request and then close it without saving.

I hope that you could implement the snap shot or locking mechanism that would be really useful and would let us use insomnia instead of postman. Also tabs would be very usefull...

[akrz]

Tabs would be great. Is there a way to create a plugin that display tabs?

[far11ven]

Has there been any progress in this area? @gschier

[lukik]

I've been coming to Insomnia on and off over the last few years. Every time I get here, I import an API collection from postman with hundreds of APIs only to find that in Insomnia I can't open multiple tabs. So I usually close Insomnia and go back to Postman.

Prominence All opened issues requesting for multiple Tabs (e.g. #1175 and #1123) are marked as duplicate and linked to this one. However, this issue (#1003) is mostly about Temporary tabs which can still exist in a single tab layout so this issue is not an explicit request for Multiple Tabs. So my guess is this old feature request will be pending as it doesn't get the prominence is requires. Well, I guess not many people need it hence why it hasn't gotten the votes. On the flip side, I think most just do what I do. Close insomnia and got back to Postman.

This time though, am sticking to Insomnia and cross fingers that this year we get tabs!

[jordankkk]

Multiple tabs will be great

[ryl]

Not having some way to use an api in an ad-hoc fashion without modifying carefully crafted saved requests makes using this app a bummer. Postman does this better in my opinion with its "unsaved changes" indicator in tabs. Having some kind of mechanism like scratches discussed much earlier in this issue would be welcome. Anything! Please!

[RomainGaillard33]

Please add multiple tabs features for temporary work. This is really missing. Thank.

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

[maciekdragan]

This is basically whats preventing me from moving over from postman to insomnia.

Same problem here. I wanted to move from Postman after finding great insomnia features: JSONPath filtering and GUI flexibility. But no tabs is deal breaker for me. Also 3-year open github issue without decision doesn't convince me to check if anything has changed in the future.

Goodbye insomnia :(

[ctadri]

This is one of the few things I am missing from postman. It would be great if this issue gets a little bit of attention

[aarrotta]

This is one of the few things I am missing from postman. It would be great if this issue gets a little bit of attention

same here

[prolonginc]

I honestly wish our company used postman instead of insomnia cuz of this feature and the workflows. tabs are essential

[robertofrontado]

Same here

[DuMuT6p]

Hello, I think this issue shouldn't be something Insomnia differentiates from Postman. It is very intuitive feature to have.

[gatspy]

this is very useful feature.

[LIVelasco]

This would be a really awesome feature to have

[Berns89]

This was requested in 2018 and still no tabs? Damn. We were asked to switch to insomnia only to realize that there is no tabs functionality?

[biko8]

Please! Add this feature, I need to have multiple temp requests opened at same time. On my team are thinking to return to postman... only for that!

[robinbertram]

Installed Insomnia (again), imported my Postman project, edited a request only to realize that everything I do still autosaves. Guess our company will stay with Postman :(

[shalomeliy]

Our company want's to replace Postman but this multi tab feature is a deal braker Can someone answer when the multi tab feature will be available here