Skip to main content

Is Your Postman Delivering Too Much? Postman Alternatives


I've been a long-time user of Postman, and I've seen it grow throughout the years. All I need from Postman is a REST client to check my API endpoints. Recently though, as I opened Postman and had to click through three offers for services I will never use, I started thinking that I should take a survey of alternatives with less bloat and take them for a test drive. 

Below are the services I found that serve the purpose of simply sending requests to an API among a few the other features that went into consideration were: 

  • Request History
    • The ability to recall previous requests was second only to sending requests in my priority list while evaluating clients.
  • Post Response Testing
    • If doing repeated testing against an API having the ability to test the responses via JavaScript in the client can save a lot of time. 
  • Collections
    • To go hand-in-hand with post-response testing, collections are a great way to organize requests if you're working with multiple APIs, such as I do as a consultant. In previous lives, I worked with only API, so in those cases collections become less important.

Hoppscotch is a simple web-based interface client, with an available Universal Windows app for download. Unfortunately, Hoppscotch does not inherently support local testing, but there is a browser extension that fills the gap. Once I installed that the extension, I found Hoppscotch quite easy to use. It has a minimal interface, which I appreciate opposed to Visual Studio's cockpit's-worth of buttons, dropdown menus, and tools that 80% of us only have a vague idea of its purpose. The desktop app even has a "Zen Mode" which removes the text labels from the side menu. (I do this with my phone apps too, my partner has no idea how I'm able to find anything!) Testing in Hoppscotch is accomplished through their own assertion functions and runs only one test script per request. This can make for some difficult test development if you need to test several pieces of the response. Essentially, you'll need to AND all your test results together, meaning a failing test could leave you scratching your head for a bit. Overall, Hoppscotch fills the role of "just an API client" very well. If you're doing local testing, you'll have to deal with the additional setup, and having an extension attached to your browser which your IT security folks may not be a fan of. If you're willing and able to use the extension, Hoppscotch is a great overall experience. 8/10 as a UWP, clean & simple

Same as above, but Zen Mode Activate!


I was turned onto Insomnia by a colleague and as an insomniac myself, I felt I had to give this client a try! Insomnia is one of the more robust clients I test drove. It sits at the cusp of usability and bloat, in my opinion. Insomnia offers a full-featured experience, included my top three priorities: history, collections, and testing. I was quite impressed with Insomnia's testing feature. Using the Chai API for assertions, I was able to assemble simple tests within seconds. Even given my zero previous experience with Chai, I was able confirm various pieces of the returned data without having to curse once! Any developer that works primarily in the backend, knows exactly what a blissful experience it is not having to curse at your JavaScipt to get it to work can be. I digress, Insomnia's testing capabilities extend beyond individual tests and allow you to run an entire suit of tests at once. This feature makes for fantastic regression testing, as you can fire off multiple requests to different endpoints, each getting their own response to run the test script against. If you're willing to put in the work, Insomnia can even chain requests for testing, taking values for the previous request and supplying them to the next. Insomnia, despite beginning to get into the territory of "features I'll never use", is the best well-rounded Postman alternative I encountered during this venture. 9/10

Clean, simple, powerful

Sweet testing suite!

Thunder Client

Thunder Client is another tool in the Swiss Army knife of development that is VS Code. I love VS Code, I'm always on the lookout for ways to get more use out of it. So, Thunder Client fits right into my daily use. Thunder Client lacks some of the features that I've taken for granted in the previous two clients. It lacks the ability to bulk edit query parameters and does not provide easy GraphQL queries. If those are important to you, maybe Hoppscotch or Insomnia are a better fit for you. That out of the way, Thunder Client supports all my big three wants in a client. Thunder Client's testing is a simple dropdown query builder. With a few selections, given limited functions, you're able to quickly put together tests to examine components of the response. However, if you're looking to do more advanced testing, again you'll need to go elsewhere as Thunder Client doesn't provide access to the JavaScript generated from the dropdown selectors. Thunder Client is a great way to fire off requests if you've already got VS Code open and just need to get to that breakpoint to see where that null reference is popping up. I wouldn't suggest it as a tool to cover all your documentable cases, but it's a handy debugging tool attached to an application you likely already have open. 7/10

Thunder Client in all its glory

Simple test generation!

Honorable Mention


Yet Another API Development Environment (YAADE) is a container-based API client that you can simply pull the container, install a browser extension, and you're off and running. This brings the convenience of a web-based approach to your local environment. Unfortunately, Yaade does not appear to support testing JavaScript on return at this time. However, it does provide for collections and history. I don't use containers in my day to day, and I didn't want to get involved with dealing with containers at this time, so I gave this one a pass. If you use Yaade, or are set up to try it out, post a comment below and let us know how it is!

Disclaimer: The above views and opinions are the author's alone, and a not endorsed by the covered applications, the author's employer, or any other associated entity.


Popular posts from this blog

The 1001st Piece in your 1000 Piece Puzzle: .NET Default Interface Functions

I was recently working with a client who wanted a reasonably large subsystem added to Optimizely that would add automated management to their content. While cutting the code for this, I found myself writing similar code across multiple classes. The reason why I had to write it that way was: 1) The client was currently on CMS11 and didn't have access to newer language features; 2) The hierarchy of the classes prevented me from inserting a common ancestor. Thankfully, .NET has expanded the functionality of interfaces, so we can take advantage of those within Optimizely. With .NET 5, Microsoft introduced default implementations on interfaces. Now interfaces can bring along a default implementation. Resulting in all classes that implement the interface can use the default implementation or override it with custom logic. Enough text! Let's code! Original Interface The following code is something that we'd create for an Optimizely experiment: using OptimizelySDK; using Optimizely

Optimizely Gets More (Case-)Sensitive

As Windows developers, we don't always have to pay attention to capitalization when dealing with paths and URIs. With CMS12, Optimizely has started deploying to a Linux container for hosting sites. This means that deployed sites (and developers!) will have to pay attention to capitals in references. Inconsistent capitalization can cause 404 errors in unexpected places. Thankfully there's a few ways to handle that!  The worst part of this is that developers won't be able to find these issues until deployed to Azure, with Windows, being case in-sensitive and all. Once named, files and folders can be difficult to change in git. Below are some ways to help rename your files so that they'll play nicely in Linux. Rename via Git mv Command   One way to update capitalization is by the git mv command. In you git command shell:  git mv <source> <target> This command will rename a file or folder, however it still runs in the context of Windows. If you want to simply ch

Config-Per-Site in Multi-Tenant Environments

Recently, a task was given to me at work where we needed a multisite configuration. We all know that multi-environment is as easy as appsettings.<environment_name>.config. What about in multi-tenant environments? You can't have appsettings.site1.config and appsettings.site2.config in your site! Well, not without a little extra work... Allow me to introduce  AddKeyPerFile ; this handy little function that you set up in your Program.cs will enumerate the files in a directory and add them to your Configuration.  "Alright!" you must be thinking "Show me how this miracle function works..." Well, let's get to it! First, you'll want to identify the config sections that will be unique to each site and put them in their own folder. I do this by site name because it makes the most sense by our conventions, if something else works for your practice, these names aren't set in stone.  Now, in order to suck those values into your config, there's one simp