DEV Community

Cover image for 🏄‍♂️ Insomnia: Quick & easy API development and testing
Vic Shóstak
Vic Shóstak

Posted on

🏄‍♂️ Insomnia: Quick & easy API development and testing

Introduction

Hello, DEV World! 👩‍💻👨‍💻

In this article, I'm going to tell you some useful techniques for developing and testing APIs in Insomnia, so you can start applying them to your work every day.

☝️ If this is the first time you've heard about Insomnia, I'll give you a quick reference. So, Insomnia is an open-source, cross-platform API Client for GraphQL, REST, and gRPC. Available for Mac, Windows, and Linux.

📝 Table of contents

Postman VS Insomnia

In fact, there is no “confrontation” between these two wonderful tools, sorry!

Everyone chooses what is closer and more comfortable to her/him for everyday tasks. I will just give my reasons why, for me personally, Insomnia is a much better performing API client than Postman.

🤗 Please note: This is just my opinion, if you are satisfied with Postman, then I am truly happy for your choice.

Pros of Insomnia (against Postman):

  • Application speed;
  • User-friendly interface of the application;
  • Functionality to use dynamic data from the responses of one API request in the scenarios of another request (within the same collection);
  • Ability to customize the usual “IDE-like” fonts;
  • Many great plugins from the community that extend the capabilities of the main application;
  • A variety of excellent design themes (by the way, the “One Dark” theme used in the screenshots of this article);

Cons of Insomnia (against Postman):

  • Slightly more aggressive paid subscription model (every day, a small banner will appear in the bottom-right corner of the app screen urging you to upgrade to a paid plan);
  • Not so great possibilities for organizing multi nested API collections (there is only separation by different folders);
  • Probably not as “pixel perfect” design as we would like (this can be seen in the app settings);

↑ Table of contents

Use environment variables

One of the most important things about designing, developing, and testing a REST API is the ability to quickly see the results in different environments.

Insomnia copes with this task, in my opinion, better than all analogues. Go to Manage Environments section, create a new Sub Environment, or add everything to the global ones. The notation for creating variables is simply JSON, which you can use for structures for variables of any nesting!

You can also add a color to help you quickly identify the right environment from the list (especially when you have a lot of them).

Env vars 1

They are now available in a handy switch in the upper-left corner of the main application screen. To call the environment variable, start writing _. (the underscore with a dot) in the right place. Insomnia will tell you which variables are available for the selected environment.

Env vars 2

In my example from the screenshot, I've these variables:

{
 "base_urls": {
  "v1": {                              // <-- version
   "auth": "http://127.0.0.1:5000/v1", // <-- auth server
   "api": "http://127.0.0.1:5000/v1"   // <-- api server
  }
 }
}
Enter fullscreen mode Exit fullscreen mode

☝️ Don't be confused by the fact that both of my servers have the same local address http://127.0.0.1:5000/v1! Since I work with microservices, it's easiest to test them locally on the same address and port. On production, of course, they'll have radically different addresses.

If I want to put the base URL for my auth server in the query, I just say:

_.base_urls.v1.auth
Enter fullscreen mode Exit fullscreen mode

And voilà! 😉 According to my rough observation, this operation alone serves to perfectly increase the speed of the REST API developing.

↑ Table of contents

Use data from other responses

The next very cool thing in Insomnia is the built-in function of transferring the received data from the body of one API response to the request of another. It's probably not clear in this explanation, let me explain it with a simple example.

If you have a closed part of the API methods, which are available only after passing the JWT check, you may encounter a problem when testing.

And you will always need to:

  1. Authenticate the user to generate a valid JWT;
  2. Copy this JWT into another API method;
  3. Make a request;

Isn't that too much to do? 🤔 Thanks to Insomnia, we can shorten this process!

First, let's decide from which response body we want to take the token. In my case, it is the method that is available on the /v1/user/login endpoint. If authorization is successful, a response will be returned that contains the following:

Data from response 1

Good! Now we have to define the place where we will insert this token. I have a private method in my test project to change the user's attributes, located on the /v1/user/update/attrs endpoint. That's where we will use the received token.

Go to the authorization settings, choose the auth type, and in the field with the value enter the word “body”. Insomnia will offer many options for placeholders, choose “Response ⇾ Body Attribute”:

Data from response 2

Next, select the desired settings from where to get the data (specify the endpoint where the user authorized) and enter the path to the data in this notation (in the “Filter” field):

$.jwt.token
Enter fullscreen mode Exit fullscreen mode

Thereafter, Insomnia should show the data that it will insert:

data from response 3

That's it! 🤩 Now all you have to do is authorize, and the received JWT will be inserted automatically to this endpoint.

↑ Table of contents

Use timeline tab for the research of request

Another of Insomnia's coolest features is the full timeline view of the request: what was sent, with what headers, what came in response, and how long.

In my daily work, I often use this opportunity. Because it's great for figuring out where something might have gone wrong:

Timeline

↑ Table of contents

Troubleshooting

Every so often, when you test the API locally, requests for which must be authorized via a header with JWT (and it’s updated must be via a cookie with a refresh token), you may get an error: refresh token not provided (although it's in Insomnia cookie settings).

This happens because you use Secure cookie to store the refresh token, but you send a local request without HTTPS (i.e., not secure).

🤓 Read more about why this happens in this article.

To be able to work with such endpoints, just turn off Secure in the cookie settings, like this:

secure cookies

↑ Table of contents

Photos and videos by

  • Insomnia authors feat. Vic Shóstak

P.S.

If you want more articles like this on this blog, then post a comment below and subscribe to me. Thanks! 😘

Discussion (3)

Collapse
sixman9 profile image
Richard Joseph • Edited

I've been using Insomnia for over 3 or 4 years now, I know that Postman has a huge following and VC money behind but if it wasn't for the fact that my teams shared collections, I'd never leave Insomnia, given its ease of use.

I had a few guys start using Insomnia after seeing me use it, they also seemed to think its UI was easier to use, to.

Collapse
koddr profile image
Vic Shóstak Author

Hi,

Thanks for reply!

That's exactly what I think, too. Postman's interface is too heavy and easy to get lost in. Especially when you just start working with it.

Collapse
pervezc profile image
Pervez Choudhury

One of my favourite feature is the “Prompt” feature you can configure on requests. No more hacking urls to change ids or manually tweaking various parts of a JSON body per request.