Leading Open Source API Client, and Collaborative API Design Platform for REST, SOAP, GraphQL, and GRPC
There is a reason developers love Insomnia. With our streamlined API client, you can quickly and easily send REST, SOAP, GraphQL, and GRPC requests directly within Insomnia.
Design APIs using OpenAPI
Accelerate your teams through spec-driven design-first API development. Catch issues earlier, centralize standards, and adopt an API workflow that works with your existing tools.
Centralize and Automate Tests
Automate manual API tests and integrate with your CI/CD process to build out an API testing pipeline using Insomnia Unit Tests and Inso, the Insomnia CLI.
Connect directly to Git providers to always be in sync with design changes and enable a GitOps pipeline with Inso, the Insomnia CLI tool.
More than 17,000 developers love Insomnia
If you are still using postman for manual REST/GraphQL API testing, I can highly recommend to switch to @GetInsomnia. If you are setting it up properly the workflow is much easier, the UI is cleaner and it also looks better. 💅
Simon Schubert
If you're not using @GetInsomnia when developing an API, you're not living.
James Brooks
This is by far my favorite kind of insomnia 😆 I've loved using the @GetInsomnia app during this week's @LambdaSchool Node.js sprint to test my API. It's incredibly user-friendly.
Emily Ryan
Interesting to me so many resources still point to Postman for API, I really like Insomnia much better (not just REST also GraphQL)
Sarah Drasner
Discovered Insomnia today, and like it much better than the more popular Postman. Feels a lot more easier to use and less confusing.
Daniel Rotter
@GetInsomnia thank you for making it super easy to make OAuth 1.0 requests 🙏
Paula
Read the original article
Comments
Nice, one thing that gets me paying for https://paw.cloud is the ability to chain requests
ie. GET /things -> GET /things/{things.first.id} -> PUT /things/{things.first.id} -> DELETE /things/{things.first.id}
Postman can do that and a lot more as it has a proper scripting runtime. The runtime can be executed outside of Postman too so you are not tied to the GUI want to automate things (with build systems etc.). Chaining as a feature in itself is something we are working on along with speeding up workflows around variables (environments, globals etc.) [Postman founder here]
By mittsh 2016-09-0620:20 I guess it's a matter of choice, but we see Paw as a visual tool that makes it easy to setup a request (or a set of requests) to iterate quickly when developing an API or discovering a new one. Because of that, we try to keep actions intuitive and keep scripting as a last resort (JS scripts & extensions are available in Paw too, btw).
I know from experience as an iOS developer (then Python backend guy) that when working on a given project, our mind is already full of business logic. We don't want to add another level of complexity due to the tools we use. And we're writing enough code elsewhere to not want to write code in an app.
As of scripting used for "unit" testing, we have thought about it many time for Paw. And while we will do something somewhat related in the near future, it's a slippery slope. A robust API should have unit tests written with mocks and be part of the server code, not a few assertions made in a 3rd party app. We're quite biased here: many users want this feature, but we don't want to encourage bad practices (as it may be interpreted by some as "ok let's not write proper tests, there's Paw for that").
Anyway, that was to share my point of view as a Paw guy :)
A comment like this is precisely why I come to HN. This product looks amazing.
By oliyoung 2016-09-063:24 It is WELL worth the $50, or $9/month on a team subscription plan
By lillesvin 2016-09-0622:42 Not saying it's necessarily easier or better, but I tend to end up doing such things in Bash with curl/wget and jq: https://stedolan.github.io/jq/
By petarb 2016-09-066:58 I had no idea you could chain requests in Paw! Thanks for sharing that useful tidbit.
By justabystander 2016-09-1611:07 I was looking into doing this today. Specifically, I needed to reference a particular property (a token in the JSON/XML content) in future requests. The docs discuss using the nunjucks templating engine, and nunjucks supports setting variables in the template. But there's no clear indication how I could set the environment variables using the response data (either manually, automatically, or using some hybrid by pre-defining buttons to set values).
I'll be interested to hear when you have some sort of chaining or environment variable setting in place.
Postman can do that too, albeit in a hacky way. https://www.getpostman.com/docs/chaining_requests
I just downloaded it to try it out and it seems you can't import any definitions other than a proprietary one, as far as I can tell. I was excited to use something other than postman, but we have WAY too endpoints to be writing it all manually instead of leveraging swagger. Maybe I'll check it out next version, I hate how the environment variables work in Postman.
By johns 2016-09-0614:50 Check out how our chaining and env vars work. We have Swagger import too. https://www.runscope.com/docs/api-testing
By mittsh 2016-09-0615:12 If you're trying to import Postman collections into Paw, that's easy https://paw.cloud/docs/migrate/postman (all requests, grouping, environment variables, etc. will be preserved). Once imported, you can even generate a Swagger https://paw.cloud/extensions/SwaggerGenerator
Since everybody's piling on their favorite alternatives, I have to mention HTTP Prompt [1]. It's obviously in another league than Insomnia and such, but I find that it strikes a sweet spot: much more convenient than curl or HTTPie, yet not a big mouse-driven GUI tool.
By joelthelion 2016-09-068:221 reply Pretty cool, but I wonder why it doesn't preserve history by default between sessions.
By tomduncalf 2016-09-0615:54 Is there a way to make it do so?
By cyberferret 2016-09-062:414 reply Seems cool - I am going to download now and try it out.
Tip: I suggest removing the 'pricing' menu option on the top of the web site. I saw it immediately the first time I went to your site, and I assumed yours was a paid product, so I stopped there and closed the window. It was only when I went back later and scrolled through, I noticed the current version is free for now. Removing the 'Pricing' link may make other people stick around longer to take a look...
Conversely, pricing is one of the first things I look for (on the assumption that good tools cost money but provide value).
If you're always going to have a free version, great put that on the pricing page along with any premium options, but don't make me go hunting through your site to find what paid options you have.
By cyberferret 2016-09-065:00 Just to clarify my position - I run for profit web apps too, and have absolutely no objection to any developer putting a price on their products or services.
It is just that in this circumstance, I am already a happy user of the (free) Postman API testing app, and whenever I see anyone talk about a new API testing tool, I am keen to check it out. However, if the other product is a 'paid for' product, then it has to be VERY compelling indeed to make me switch from the free one I am already using.
For instance, I (and many others) think that Paw is worth the licence fee. It sounds a great product and is well worth the money. But for me, I didn't see any solid reason to switch to Paw from Postman unless I came across an absolutely killer feature that I could not live without.
In Insomnia's case, I was ready to dismiss it because I read about the simplicity of the interface, and I saw a 'Pricing' link on the web page. I immediately assumed it was a paid licence product, which meant that it immediately fell outside any compelling reason for me to even trial it.
Later, when I saw that it was an always free piece of software, it immediately went back on my radar as something I should check out as a possible replacement for Postman.
If it is as good as others say, then I do sincerely hope that the author finds some way to monetise it via some sort of Pro subscription etc. in the future.
My point is that the presence of a Pricing page (which I admit is one of the first things I look for when I visit any app or service page) could mislead people into thinking it is a strictly paid-for app, when in fact it is not.
By newscracker 2016-09-0612:14 I hate it when pricing is not a prominent link on a site's homepage and has to be found through a web search. It always look quite shady, like the enterprise software/services market where "call for pricing" is more common and always seems like an extortion is about to take place.
For consumer/small business related apps/services, if I don't see pricing linked or mentioned on the home page, I assume that it is quite expensive and that the developer/company believes the same too, thinking that people will balk on seeing the price and that they can somehow be convinced to sign up first (so they can be marketed to) and then pay what's demanded after reading the long list of features or other fluff they put up.
That's great feedback. The app is (and always will be) free so de-prioritizing the pricing page is probably a good idea :)
By cavemanklaus 2016-09-063:422 reply I'll add that when I see no Pricing page it causes me suspicion, what's the catch? how am I being dataminded? I'd at the least explain somewhere on the page how pricing works or how this is free and funded.
Yep. Developers need to earn money. If I don't see a pricing page I start to wonder about how they are making their money, and more importantly if they have a sustainable business model. I don't want to rely on a tool that then goes out of business.
Yes, developers need to earn money. I know, I'm one (like probably most users of this software). Sometimes developers release open source software, earn money with a different job and the project doesn't go out of business (because it's not a business). This is something I was used to explain in the 90's, I didn't expect to have to explain it again in 2016.
No back to "businesses". When I see a free version and a paid version, and I know the difference, I can decide whether I want to use the free version, pay for the paid version or use neither.
However when I see "everything free for now but paid version later, the difference between the 2 unclear", it worries me that there will be some bait-and-switch, and the free version will be gimped or will get ads.
By imron 2016-09-068:41 > This is something I was used to explain in the 90's, I didn't expect to have to explain it again in 2016.
The world, the Internet, and in particular revenue models for software and services have changed significantly since the 90's.
If I land on some project's Github page I'm not going to be looking for pricing.
If I land on the marketing site for an app I'm going to assume it's a business and look for pricing first.
I remember the 90's too. You didn't have half the dark pattern/bait-and-switch/datamining revenue models that are commonly seen these days (and there are enough companies that have left users high and dry at the end of their "incredible journey" that app/business longevity is also a valid concern).
And so now, in 2016 I'm more cynical and one of the first things I want to know when I come across a potentially interesting app/product is how they plan to make money off me.
If it's all open source, great, say it up front. If it's free with various premium options, fine, say it up front. If it's subscription based service, no problem, say it up front.
Just don't hide the pricing page (or the open source branding) from the front of your site, which is the context in which I made my comment.
By tokenizerrr 2016-09-068:19 The catch is that it's free and open source? At least that's how I usually interpret it, even though Insomnia doesn't seem to be open source (disappointing).
No, but i think you should leave it there. Pricing should be upfront otherwise it creates suspicion and distrust.
By newscracker 2016-09-0612:20 It could be prominently mentioned as free on the homepage instead and avoid making users navigate pages to find information.
Not like "download free for <platform>" (as it is now on this site), but as "free to use, download for <platform>" or something similar.
So I decided to keep the pricing link but add "free" to the download button. I think that's a pretty good balance.
By cyberferret 2016-09-065:281 reply The "Free Download" thing has been done to death though. It almost always is a guarantee that we can DOWNLOAD the app for 'free' but will have to pay when we want to actually USE the app.
I think the best alternative is to put a callout in your header somewhere that says something like "Basic version of Insomnia is free forever". Then retain the Pricing page for people who may be curious about your 'Plus' version.
By gschier 2016-09-067:16 Ya, I thought about that but decided on the "free download" for now to get it out the door. Definitely agree though.
By kovrik 2016-09-067:13 Wait, it is free???
Thanks for the comment! Downloading the app!
