Store response code in CSV column

[dotJson]

Hi again,
I recall you mentioned writing this to pull data and that's where the output to column map came from. I'm POSTing data so I already have that info, but would be great to store the response code (200, 401, etc) in a response column. I find if I dont set an output map in the batch dialog it does not iterate through the CSV so I have been selecting bogus fields to get it to go. I can get the response data in Insomnia already, so storing it in CSV is not critical, so maybe the option to bypass the requirement to select something would suffice.

Also, any simple way to set a default timer in the delay you implemented? Like 2 seconds?

Thanks again for a great plugin and being so responsive.

Jason

[jreyesr]

Hello! This has multiple ideas, I'l split them in multiple comments:

1. Feature: Ability to also store the response code in the CSV. Currently you can only select parts from the response via JsonPath (which, by the way, should be a JSON response, no XML or other formats).

Yes, that sounds really useful for some usecases, such as knowing which requests ran successfully. While we're at it, we may as well add support for pulling headers from the response, since I've seen cases when some important data is saved in a response header, such as the LinkedIn API for creating posts, where after you create a Post, its ID comes in a header.

How would you expect to declare that you want to pull the response code? As the UI is now, you need to write a JsonPath selector, which will always start with $, which in turn references the response JSON. I have two ideas:

One: Add more things into $. For instance, say the response contains {"message": "Created"} and the status code is 201. Currently, you can only write $.message, which will resolve to Created. We could make it so $ now holds both the response and the status code, so to get a response field you'd write $.response.message to get Created and you could also get the status code by $.statusCode. This would also extend to response headers, with $.headers["X-Custom-Header"].

Two: Modify the UI so that you choose the context that the JsonPath selector will be evaluated on.
For an example, you can try the OS template tag, which comes built-in with Insomnia so you should have it installed. In particular, see the cpus and userinfo functions. Those return JSON and you set a JsonPath selector to choose the parts of the response that you are interested in.

I imagine something like that for the Output fields, where we add a new dropdown to the left of the JsonPath textfield. It could default to Response Body, but you could switch it to Status Code (or maybe make it a more general object with response information such as status code, time taken, number of bytes) or Headers. For example, if you set the dropdown to Headers, then the JsonPath query to $["X-Custom-Header"], you'd be able to extract a response header. For your usecase of getting the status code, it could be setting the dropdown to Status Code and the JsonPath query to $, or (if we go the route of exposing some more info) setting the dropdown to Response Metadata and the JsonPath query to $.statusCode.

Do those sound like they would solve your usecase? The first option would be easier, the second one would be more elegant. Any preferences? Does the second one seem intuitive enough? For example, see the UI below. Does this clearly say "the selector $.company.name will be applied to the response data"? By the way, the middle dropdown has options "Response body", "Metadata" and "Headers".

[dotJson]

See my other comment below. I think this is solved with allowing runners with no outputs defined. Insomnia stores response data already so capturing the response code is redundant.

[jreyesr]

Got it! I've opened #4 to track this, since it should be a bug. I'll investigate more and fix this first. Then I'll focus on the other two parts.

[jreyesr]

Actually @dotJson would you mind providing some more information in issue #4? I have been able to make a request run multiple times even with no Outputs set, see below. I did find a case when it did get stuck at the first iteration, that may be your issue in disguise. Thanks in advance!

[jreyesr]

In particular, I'd be interested in:

• How is your API response? Is it valid JSON? Or is it XML? You did mention XML endpoints before. If the API responds with XML, that would be a cause for the error.
• Are there any errors in the DevTools console? You can show it by pressing Ctrl+Alt+I and navigating to the Console tab before clicking the Run button that gets stuck. I managed to get the runner stopped after the first request, but that was when I was pointing to a localhost address that wasn't even valid. That did appear as a red-background error in the Console.

[dotJson]

Of course, I use two API’s; one XML and one JSON. The XML is the one I’ve been testing. I did see the response error about content type but did not associate it to the iteration stops. I will need to try shortly to get console logs.

[jreyesr]

Hello! I've released version v1.1.1, which should fix the bug. Now, if you don't provide any Output maps, it won't even try to parse the response body as JSON, which is what was making your XML request hang after the first request.

[jreyesr]

• Feature: Add a default timer in the delay.

How do you imagine setting that? Would the default apply across ALL your requests? Sort of a "plugin config" that stated "whenever I open the Batch Requests dialog, the Delay field should be set to X"?

If so, it's... kind of weird. The folks at Insomnia don't seem to provide a ready-made API for a plugin to declare that it has some config. I'd have wanted a "Settings" button to appear besides my plugin in the plugin list, but I couldn't see any such functionality.

That being said, see this plugin for a sort-of workaround. They add settings that are collection-wide. That's one level below applying that to the whole Insomnia installation, but it may be good enough.

Would a workspace-wide "configuration" option satisfy your need?

[dotJson]

For MY use case I’d say 99% of my calls are runners that need the delay to avoid the rate limit. That may be a unique problem others don’t hit, but literally every time I run a CSV I set the delay to 2sec.

[jreyesr]

Hello again! Just wanted to announce that v1.2.0 is now available, which includes the ability to set a global default delay. See the README for instructions.

After you set that configuration option, every time you open the Batch Requests dialog, the Delay field will be preset to whatever you specified in the Preferences dialog.

You're welcome to test it out and report any weirdness that you experience.

[dotJson]

Perfect! Works as I expected and is exactly what I was looking for. Thanks for all of your efforts on this.