fullpacknow

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:). 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. 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.

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. 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!

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. I cannot agree more on this:) The first time I saw Insomnia last year, I found it already very well designed. It had a smooth UX on most basic actions and, I have to say, a fun use of the '.rest' domain name!

I'm the founder of Paw and I can safely say that building a good UI is a lot of work. While Paw is built on native Cocoa/AppKit (OS X app framework), the challenges with web are different, but the amount of work is always here. Each custom control, tweak on the text fields and other sorts of custom behaviors are taking a lot of time to imagine, design and implement. But it's a lot of fun too! Clearly Insomnia is one of these apps where by just landing on the website you know that it's made my someone who has a good taste and who pays attention to details. As of the app, most common Mac shortcuts are working. And the fact that you cannot open the Chrome console (Cmd+Shift+I) or select text outside of user inputs are a proof of a well polished product.

It's often hard to make a point about polished UIs because it's highly subjective and it's common to see people wanting to compare only 'raw features' between two products. I'm not a big fan of Electron apps, and Paw and Insomnia are somehow competing (one native, full-featured with extensions and dynamic values, team syncingthe other being a more lightweight version), but I must admit that Insomnia is nicely made!:). 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. 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? Tried out the Chrome plugin when RESTClient stopped working in Firefox.

It stuck, and now I believe all of my small team uses it. I've been on the stand-alone version since release. I use it for testing, but also more as a diagnostics/control panel for a software suite that we expose via a growing HTTPS API - saving the requests and payloads makes this easy. One thing I miss from RESTClient is the formatting. We have a small JSON DSL that we exchange data with, so those strings have to be escaped going up, and of course they come back with all the escapes.

Rest Client Alternatives For Mac Free

In RESTClient, you could view the response 'formatted', which would un-escape those strings. This made for easy copy and manipulation. I've used Insomnia in the past when I was evaluating various REST clients. At the time I was using mainly Burp and sometimes Postman. I did not stick to it mainly because I could not find some features that I needed for my work.

From what I can see on the website, the new update is around the client apps built specifically for Mac, Windows and Linux, which in my mind is a welcome addition. That being said, I will definitely have a look to see what is new.

Since everyone is putting their favorite REST client - here is my own (disclosure I am the author). I've built it to fit my own needs and combine essential features from other clients which I find useful. I looked mainly at Burp, Postman and of course Paw for inspiration. The tool is available at the Chrome App Store here: You can also access it directly from here: It is a work in progress but it has some features I am yet to see in other web-based REST clients, such as:. Dynamic fields and variables that are re-computed on the fly. Built-in text transforms that allow me to recompute a value in its original form.

Support for constructing multi-part requests with data and files easily. The ability to modify file names and file types in multi-part requests. Handle all headers (even those which are marked private in the Chrome and Firefox APIs). Works in both Chrome and Firefox - on problem.

Locally cached for offline use. All requests originate from your own machine - the tool runs locally. Pretty-print everything including JavaScript, CSS, XML, HTML and many more. Pretty-print any type of form and request payload. Automatic code generator. The reason it is a work in progress is because the current online version is at leas 3 versions behind from the libraries we use internally.

We have scheduled some work to bring it up to date and we will be adding local storage and remote storage support very soon. The tool is 100% free and it is part of our new tool stack at secapps.com. I need to say that we are revamping our current business model so that we can provide all of the tools free of charge to the larger community. These changes are not reflected on the site yet but I will as soon as the new stack is completed. And if you are interested in these kind of stuff, here are a few more tools also free of charge: Apologies for intruding into this post but I thought there is a good opportunity to suggest some alternatives as I've seen other people do.

Insomnia is still great though and I am sure some people will prefer its looks over other clients.