We have considered a Paw Light, if it were to come it would be a little diffrent from Paw. More focusing of throw away requests than building large projects. If we put work into it we would like it to still bring value to our Paying customers. But currently we have a lot on our plate to bring Paw to a feature complete state.
And it can also generate program code for a lot of languages, curl or wget requests etc, and is has the interceptor plugin.. cant really be beaten at this time...
Swagger UI seems to do a pretty decent job. The thing I like about swagger is you create one canonical description of your API and model and then generate postman collections, API docs, and client/server stubs all from the same source.
Swagger is now OpenAPI with backing from many major corporations.
We use it to deploy APIs tailored to each customer, as we can adapt the view and still reuse controllers and models. Documented and maintained.
I've been using Postman/Newman for testing and really liking it overall. One thing I'd love to see in one of these apps is the ability to use web sockets in tests.
Great suggestion. Websocket support is definitely something I've been thinking about adding later on. I'd love to hear any suggestions you have on what a websocket testing workflow would look like.
I would be happy with very basic support. Just something that can save messages and connection urls. A nice JSON viewer/editor like you have already would be very helpful to me as well. The current options for websocket testing aren't that great.
Thanks for the question! Insomnia is an Electron app built with with a mix of React and Elm. As an independent developer wanting to reach all platforms, Electron was basically the only option for me. And, as a web developer, it's been a super productive development environment.
The goal for Insomnia is to build a REST client that's easy to learn and a joy to use. I looked into other REST clients before starting Insomnia and found them to be cluttered and complicated. Paw was my favourite, but I needed something cross-platform so was unable to use it.
Python with PySide (Qt) is always my cross-platform choice. Though I suppose if the OP is a web developer then Electron (JavaScript) would be easier to learn.
I think he meant the only option as a web developer. Maybe he doesn't know C++ and C#, and it's not that easy with a web-oriented mindset to start writing desktop apps in C++ (it's not easy the other way either, I had a friend who after years of programming in Delphi started with the web by absolutely positioning every single HTML element).
When someone asks in which lang should he implement a webapp/SaaS/whatever, the first comment is to use the tech he knows the most. Why so much hate when the same principle is used for desktop app development?
heh, yeah I think he meant that as in that's where his experience is. For me it would be 'As a ops engineer, I wouldn't generally host Javascript apps' to spin it around the other way you know?
Personally my laptop needs to run two browsers an ide and a couple of other programs - as well as a local instance of what I'm working on. This leaves ram+cpu for 0.5 electron apps one runs but now my system is a slug... So I'll not be able to use this which is a shame.
Something like qt is just as cross platform without the performance penalty... So I am sad you took this choice :(
Yes! I've been using Insomnia since it was a Chrome extension and the new 3.0 release is an amazing upgrade. I strongly agree with the developer that tools like Postman are quite bloated and complex for normal development tasks. Insomnia is very lightweight and refreshing!
I covered this a little bit in the comments below, but one of the reasons I created Insomnia was because I found other tools (including Postman) to be hard to learn and use. So, for me, the main advantage is having a clean and simple (but still powerful) interface. Insomnia also has a Linux desktop app, which makes it one of the only REST clients to support all three major platforms.
Insomnia is still in early stages, so if you have any feedback or suggestions I'd love to hear!
I find the visual design appealing, and at a cursory glance, the list of features decent. A few questions:
- Is there a way to override the cookies of a single request? Or do you have to edit the cookie jar and the corresponding cookies get auto-sent (ie. no override)
- For authorization, do you have built-in support for OAuth 2.0 access/refresh token flows? What about OAuth 1 ?
Thanks for the compliment! Having good UI/UX was my first goal for Insomnia so I'm glad to see it's working.
- there is no way to override cookies per request yet, but that's good feedback :)
- I'm working on OAuth support soon so keep an eye out for that
- HTTP/2 support isn't in the works yet, but is on the roadmap
A lot of people here have been mentioning Postman but my personal go-to has been Advanced Rest Client [1]. It's open source, has Google Drive integration, and seems to have a pretty impressive development rate. For me, it's a definite plus that there isn't a paid tier so the developers don't have any incentive to limit the free product. That said, Insomnia looks like a nice contender and I look forward to giving it a shot. The reuse of variables across requests and the automatic generation of boilerplate request code both look like really nice features that ARC lacks!
Ya, ARC is a pretty good one! Have you heard how the developer is handling the announcement of the shutdown of Chrome apps in 2017? Curious if they'll hop on the Electron bandwagon too.
As an author of the ARC. I'm considering using electron and move to native apps and discontinuing Chrome integration. But right now I'm not focusing on it. At the end of last year when I started moving the old app to new packaged apps platform I already knew that some changes are necessary and I started to modularize the app into web components (using Polymer framework) to be able to relatively fast move to another platforms with minimal change in the code. So UI components are using web only features, app logic only javascript and non-chrome related APIs and finally Chrome related components that can be easily replaced by other platform's implementation. So eventually (this is ongoing task) I'll be able to move pretty much any web environment.
For me, it's a shame it's a chrome app, rather than a plain ol'd desktop app. Having to fire up chromium to run something this simple seems like an overkill.
I've been using Insomnia since the beginning and I really appreciate how receptive gschier is to feedback and how the support side of things are handled.
I'd love to hear what you're planning on working on next and how you plan to monetize (if you're going to) :)
Insomnia is still in the early stages, so talking to users is something I spend a lot of time and effort on. It's the only way to make a good product :)
My current plan for monetization is to add multi-device sync (almost ready for beta) then team collaboration features shortly after. There are also some advanced features left to implement like OAuth support, scripting (settings environment variables from response data), and a few others.
Hi there. Could you reach out to support@insomnia.rest with details? I'd love to help get this running for you. The linux build uses http://appimage.org/ which should support Fedora out of the box.
Hi there. Can you try downloading the latest version again. Apparently the last release was corrupted for an unknown reason. I uploaded a new one though :)
Insomnia is still in early stages so the paid plans aren't entirely worked out yet. The goal with the pricing page was to put something up early to gauge interest.
Insomnia seems to be stuck in an "Install update" loop. Each time it opens I get prompted to update and restart. I update and restart and then get updated again. The cycle continues.
I'm uninstalling and re-downloading it but just wanted to let you know.
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...
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.
> 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.
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).
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.
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.
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.
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.
Unfortunately, Postman's native apps don't handle NTLM authentication, which basically makes them unusable for me. Have to stick with the chrome extension for the time being.
Great question. Insomnia is still pretty early, so the feature set is limited, but all the basics are there. Most users coming from Postman comment on the great UI/UX of Insomnia.
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.
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.
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]
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 :)
This is lovely. I wish I knew about it earlier so I could ask IT to install it on our lab machines for students to use when i teach web concepts. The Postman plugin is nice but I had trouble working with it on my own, and sometimes it's nice to have a separate app.
I keep hoping one of these clients will add IPython/Jupyter style notebook specifically for REST calls.
I would love to produce a tutorial that has well formatted URLs with params, bodies, headers and pre-saved results that could also be rerun against local server.
I think you should be able to get pretty far by just writing Python code that uses the API; using requests that should be as readable as anything else?
Which brings me to: I just use Python snippets if I want to test a REST API quickly. What am I missing out of by not using these tools?
If I am writing a tutorial using REST calls, wrapping them in Python syntax is less than effective as a presentation. It also requires Jupiter backend running, which could be a burden to host for a popular multi-user tutorial.
It is something that O'Reilly is experimenting right now with their interactive tutorials, but even for them, it is early days.
Any plans to open source this? Considering that (a) it's cross-platform since day one, (b) it's an HTTP client for developers, and (c) it's apparently built with the JS ecosystem, seems like the kind of app that should be open source, and honestly I'm surprised to see no Github link.
The Windows installer is 60MB and it's 64-bit-only? It has a nice fancy GUI and all, but am I the only one thinking that's just a tiny bit... excessive? Especially when it claims to be "A simple and beautiful REST API client". The Mac OS and Linux versions are a bit smaller, but still not quite what I consider "simple".
Also, did anyone else instinctively try decoding that Authorization header in one of the screenshots? :-)
It's based on the Electron framework (http://electron.atom.io/) so the installer contains an entire copy of the Chromium browser. I agree that it's large, but it's basically the only option for an indie developer to write a cross-platform app. Also, 32 bit support is possible, but is a bit of work and demand hasn't been high enough to spend time on it.
I agree with the word "native" not suiting Electron apps well. I Updated the pricing page wording to reflect this. I think I originally used "native" because the Electron landing page does http://electron.atom.io/
I've been using http://mmattozzi.github.io/cocoa-rest-client for a couple of years, I just tried Insomnia and I think I'll be switching: having the ability to call frequently used API requests without having to re-enter JSON data will be very useful. Nice app, thanks gschier.
155 comments
[ 3.3 ms ] story [ 192 ms ] thread(matthaus, backend dev on https://paw.cloud)
P.S. Insomnia also has code generation https://insomnia.rest/documentation/code-snippets/
What are you main goals as far as being different from Paw, which is what I use and love thus far?
*edit: oh and congratulations on getting your app out there :)
The goal for Insomnia is to build a REST client that's easy to learn and a joy to use. I looked into other REST clients before starting Insomnia and found them to be cluttered and complicated. Paw was my favourite, but I needed something cross-platform so was unable to use it.
I'm not saying you made the wrong choice, but why do you say that, given the various options for cross-platform development (Qt, Mono, etc)?
When someone asks in which lang should he implement a webapp/SaaS/whatever, the first comment is to use the tech he knows the most. Why so much hate when the same principle is used for desktop app development?
Something like qt is just as cross platform without the performance penalty... So I am sad you took this choice :(
Insomnia is still in early stages, so if you have any feedback or suggestions I'd love to hear!
- Is there a way to override the cookies of a single request? Or do you have to edit the cookie jar and the corresponding cookies get auto-sent (ie. no override)
- For authorization, do you have built-in support for OAuth 2.0 access/refresh token flows? What about OAuth 1 ?
- Do you support HTTP/2?
- there is no way to override cookies per request yet, but that's good feedback :) - I'm working on OAuth support soon so keep an eye out for that - HTTP/2 support isn't in the works yet, but is on the roadmap
Thanks for the comment!
[1] https://advancedrestclient.com/
I'd love to hear what you're planning on working on next and how you plan to monetize (if you're going to) :)
My current plan for monetization is to add multi-device sync (almost ready for beta) then team collaboration features shortly after. There are also some advanced features left to implement like OAuth support, scripting (settings environment variables from response data), and a few others.
Thanks for the comment!
I think developers have a tendency to prioritize things like pricing below the technical features.
I wrote a bit more about pricing in a past comment if you're curious https://news.ycombinator.com/item?id=12433260
I'm uninstalling and re-downloading it but just wanted to let you know.
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...
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.
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.
Not like "download free for <platform>" (as it is now on this site), but as "free to use, download for <platform>" or something similar.
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.
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.
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.
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.
Thanks for the comment! Downloading the app!
Edit: I do not mean to undermine the effort, just wondering if Postman users have any incentive to switch.
ie. GET /things -> GET /things/{things.first.id} -> PUT /things/{things.first.id} -> DELETE /things/{things.first.id}
I'll be interested to hear when you have some sort of chaining or environment variable setting in place.
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 :)
I would love to produce a tutorial that has well formatted URLs with params, bodies, headers and pre-saved results that could also be rerun against local server.
Which brings me to: I just use Python snippets if I want to test a REST API quickly. What am I missing out of by not using these tools?
If I am writing a tutorial using REST calls, wrapping them in Python syntax is less than effective as a presentation. It also requires Jupiter backend running, which could be a burden to host for a popular multi-user tutorial.
It is something that O'Reilly is experimenting right now with their interactive tutorials, but even for them, it is early days.
Also, did anyone else instinctively try decoding that Authorization header in one of the screenshots? :-)
P.S. All the data in the screenshots is fake :P
P.S. All the data in the screenshots is fake :P
I've seen a few instances where the data would decode to something like "if you can read this, we're hiring".
Was originally open-source, there is now a paid version but an OSS version is still available.
https://www.soapui.org
What ever happened to Qt, WxWidgets and the like?
That is not a "native" app.
From https://insomnia.rest/pricing/
"Native app for Mac, Windows, Linux"
Good luck with it!