I've tried to use both Paw and Postman. Always ended up going back to HTTPie (https://github.com/jakubroztocil/httpie). It's much faster than clicking through a GUI, at least for basic requests (which is what 95% of requests are).
Don't get me wrong, Paw is a really nice app, but I don't feel that it rivals the productivity of bash-jitsu for most day-to-day use.
After trying to figure out why Postman was doing a double GET this morning on a coworker's computer, I finally told him to just install httpie. Took a little while but it's much easier to be explicit about a request. Bash command history does a lot of what these GUIs do.
You probably wanna tell the Postman team[0] about this. They are a bunch of helpful folks who are working very hard on building the product. They'll be glad to see the bug report.
Full disclosure: I interned with Postman for a short duration last year.
Maybe it was actually an OPTION/GET combination? In that case, it's actually useful that Postman is running in Chrome because it shares the same environment and constraints.
HTTPie is a CLI client, and I don't think it would make sense for it to save the requests you make (as opposed to a GUI). Though, it has a nice persistence feature with sessions (https://github.com/jakubroztocil/httpie#sessions).
It's the nice thing with GUIs (Paw, Postman...)! Paw saves all your work in ".paw" documents that you can share with your team on Dropbox or Git. You can have many documents, and organize your API calls.
It can generate basic auth headers, handle OAuth workflows, store variables in different "environment" containers per project, export the request in any of a variety of formats (jQuery, curl, etc:) - it's a brilliant piece of software, and I use it almost every day.
Postman founder here. Postman let's you run tests outside of Postman through the newman tool (free) [1]. Just take collections outside Postman and run them anywhere you want. Collections can have Javascript scripts embedded inside them for request chaining (transferring data from one request to another) or just writing integration tests. Tons of possibilities and we have some great new stuff coming up around this.
We just push bug fixes now for the legacy app. The roadmap of legacy apps from Google is still not clear. I would strongly suggest the packaged app way for multiple reasons (folders, in-built documentation, syncing, real-time sharing, tests, request capture).
And yes, native apps are coming soon! Atom's Electron is a strong contender. We are exploring all possible options. :)
There are many better ways to do automatic testing. I've never used Paw for that, and I don't think it competes with e.g. postman on that front, if that's what you're asking.
However, for manual testing / having it write curl commands for you / making JSON really easy to work with by hand, it's fantastic, and I've converted a few people at work to it. Developer is also very responsive and nice to work with on Twitter.
Edit: you can also write extensions in JS for it. Not quite as accessible as e.g. Atom, but still decently hackable: https://luckymarmot.com/paw/extensions/
As the sibling comment says, there are probably better tools for automated testing. However, I haven't dove too deeply into this aspect of Paw, but I know that at the very least there is a "Run All" shortcut which runs all requests you have configured. The sidebar shows which requests succeeded and which failed. There may be some way to automate this. (It apparently supports extensions, if this functionality isn't built-in.)
We bought this app and I can safely say this is the best REST client I have ever seen or used.
The others out there (mostly the extensions for Chrome and Firefox) will do for most people but this app is just gorgeous and offers some nice features on top.
Some of the more mundane parts (JSON content in a post, basic headers) are handled in a couple clicks.
Ha, I feel the same way and started to make a little tool to help this, but most of the feedback I got was that it was pointless :( https://github.com/seiferteric/clamp
If you are quick with cURL maybe it's not--it's just a matter of preference.
I, on the other hand, can take quite a while to type out a cURL request with 4 custom headers and a long JSON body.
While I spent most of my day at the CLI I do step out for a few choice applications. Being able to quickly save and compile a bunch of requests to replay is also nice though I'm sure you could do that with cURL or similar tools.
It doesn't hurt that the app is particularly nice looking either :-)
Yeah, JSON on the command line can be a big PITA, especially when it comes to escaping. The old `curl -vvv -X POST --data @foo.json http://example.com` trick mostly works, but isn't the most elegant thing in the world.
This just might be, and it'll write the curl command for you too :)
I had been using Postman[1] for the last year or so and it's recently undergone a big update too which includes syncing. I've just tried Paw and like it more because:
- Native Mac app (it's prettier)
- I like the 3 pane window structure
- A lot of smaller UX things are nicer like duplicating, Postman annoyingly scrolls down, having to explicitly hit save, etc.
- Extensions
- Dynamic values
- Completions
Postman has the following which Paw lacks AFAIK:
- Collection automation and testing
- Chrome integration
- Dark UI theme
If I had use either of the 2 above I would not be able to switch over to Paw.
On Macs I would consider the Chrome integration to be a down side as it seems to install itself as a separate application entirely, and thus in my app launcher (which annoys me, especially when I'm signed into Chrome + Canary and then it's showing up twice).
To expand on the point "Chrome integration", the most useful aspect of Postman is the "Postman Interceptor". You can clone any real in-browser request (primary page or ajax request) into Postman, ready to be replayed or modified then replayed. The amount of time saved when you're playing with ajax requests rather than a REST API is insane.
Paw is undoubtedly the best REST client, but that said I am slowly moving away from it as it's not cross platform .
I develop both on a Mac and Ubuntu system .
I've been using this for awhile, and I think it's quite pricey for what it does, as Postman is free and offers much of the same functionality. That said, this has a great UI and the grouping feature is awesome for managing multiple projects, and in general it works very well. One of my favorite features is the ability to "turn off" certain parameters but keep them in the request, so you can switch them on/off when you want to change maybe a field or two easily without making an entirely new request.
I really would like to see the ability to type JSON out in the request body manually instead of the somewhat-clunky input field deal.
You can write JSON in the Text field, and it will be syntax colored if you add a "Content-Type: application/json" header. And you can switch back and forth between Text and JSON formats.
(I'm a Paw guy)
Not all huge companies have bosses that can see beyond their noses, and are capable of comparing the time an $30 app would save you to your hourly rate.
At the same time, if there was an app that cost half your yearly salary (e.g. $40,000) but automated all of your work and let them fire you, they'd jump all over it.
There is only really one free alternative with a comparable feature set - Postman. Postman is pretty good, but I would pay that and more for a decent (windows) alternative.
The most useful feature for me is 'dynamic variables'. I can use data value from a HTTP response as a variable in the request body for another HTTP request. It makes testing API endpoints that depend on each other a breeze.
I also like the 'environment variable' feature. I can easy test the API locally and on staging server just by changing setting different environments.
Thanks! I'm the guy behind Paw, and I must say the Dynamic Values are our kind of secret sauce :) it's just one piece of the app, but it's what allows you to do pretty much whatever you want. Extensions are also nice, as they allow you to add new features yourself: https://luckymarmot.com/paw/extensions/
I'm actually surprised by how positive the responses are for this app.
First, I'm a bit turned off by it's use of the term REST. It's just an HTTP client. Gah, I give up.
I occasionally use postman, but more likely I'm writing a script that I'm going to integrate into my automated testing anyway. Or a simple one-off script with wget. I find that faster to use than a GUI but maybe I'm just getting too settled in my ways.
What was the use case that made you switch to something like this?
Repeated manual testing of APIs at work across different environments. I used to just keep a scratch pad but with paw we were able to set it up and distribute a save file over Dropbox for the team to share. Variables for different environments were a nice touch, I guess you could bash script to your hearts content but this was a little less cumbersome.
Working on a project at work that's got about 50+ endpoints all saved in a single paw file. Paw makes it stupidly simple to go back to any of them. It also remembers headers and POST request bodies which saves a ton of time. Just found out in this thread that you can distribute paw files to the rest of your team to use. Should be onboarding new developers much easier.
Postman let's you do both. Use the GUI for explornig the API and use the CLI (newman[1]) for integrating with automated build systems. The idea is that you should not have to repeat yourself at any point in your workflow.
> REST, in the form coined by Roy Fielding, is actually almost the opposite of what "RESTful" means today,
Not really the opposite. "RESTful", when it doesn't actually refer to Fielding's REST [0], generally doesn't mean anything, its just an empty buzzword being dropped into a product description that communicates no meaningful information at all. Even then, its seems to be intended to communicate "conforming to the REST architectural style", it just fails to do so because its done without any knowledge of the REST architectural style (and not even with an consistent wrong view such that the use of the term could be said to have a particular definition different from that that Fielding laid out for REST.)
[0] Though, to be fair, it often does, although sometimes to only some particular part of it (and not always the same part) as opposed to systems that lack the part being focused on. This use is somewhat consistent with Fielding's, though it would probably be better to focus on naming the particular element.
>Not really the opposite. "RESTful", when it doesn't actually refer to Fielding's REST [0], generally doesn't mean anything, its just an empty buzzword being dropped into a product description that communicates no meaningful information at all.
Well, it instantly communicates: 1) over HTTP(S), 2) using HTTP queries (and verbs) 3) taking advantage of HTTP authentication, caching etc, 4) returning, more often that not, JSON.
I don't think any "majority" even cares about REST let alone know it exists. I also don't see jargon as something that may or may not "catch on", I see it as a way to organize ideas in a professional area so as to ease precise communication. If my peers keep changing the meaning of jargon then it makes it harder for everyone to have meaningful and constructive discussion about our field.
This all can be avoided if people make it as a rule not to reuse names for a new concept Y that is already being used for concept X. What do you see as the reason to reuse names? Do you think we're running out of them?
>I don't think any "majority" even cares about REST let alone know it exists.
Obviously, as its a technical term, "majority" here refers to the majority of the respective technical audience, not the majority across all people.
>I also don't see jargon as something that may or may not "catch on", I see it as a way to organize ideas in a professional area so as to ease precise communication.
The best way to "ease precise communication" though is to use a term as it turned out to be used/understood by most people -- not to insist of its initial intended meaning (which in IT could be off by several decades to its modern use).
>This all can be avoided if people make it as a rule not to reuse names for a new concept Y that is already being used for concept X. What do you see as the reason to reuse names? Do you think we're running out of them?
The thing is, REST initially was some random thing some guy wrote. A person totally irrelevant in the grand scheme of things, not some standards body.
REST became a thing and got relevant only after it was adopted by a critical mass, and in the process people used it in different ways, adopted what they liked, etc. Those changes due to impact with real and different uses, reflect into what people call "REST" today.
Once we called "computers" actual humans doing computations [1]. Then it was some huge machines in corporations. Now we can even call our phones that. It would silly to insist that we should keep computers to its meaning at any fixed point in time.
> The best way to "ease precise communication" though is to use a term as it turned out to be used/understood by most people -- not to insist of its initial intended meaning (which in IT could be off by several decades to its modern use).
How do we know we're up-to-date with the latest definition? And what if someone disagrees with what is the latest definition? How do we even know what "most" people think is the latest definition? Do you see how your suggestion is unrealistic?
But, your next argument is the strongest here, and I stand corrected. I like your computer example. So I'd say if we deprecate the thing that the word meant before (human computers, or REST as defined by one guy and never used) then it's OK to reuse it. I don't know the REST story and have no reason to doubt your version of it, so thanks for the argument!
To be very accurate, REST isn't necessarily based on HTTP. But we like to see "REST" or "RESTful" as the type of HTTP APIs we almost all build nowadays as opposed to other protocols built on top of HTTP like SOAP. (Frankly, who builds non-HTTP REST stuff?!)
I am looking at it and can hardly find anything that it has that free POSTMAN doesn't have. I am wondering, anyone who leaving nice comment about Paw, have you used POSTMAN before, if yes, what is it what it miss that justify non cross platform piece of software that you have to pay for?
I use Chrome. I still don't want to use the idiotic "Chrome Apps" that aren't apps at all, when I have a choice. For certain tasks I can see the value, but for things I use every single day a native app is much better (especially just for battery usage, assuming decent coding for both versions).
A native GUI? Believe or not people will still pay a premium for that, myself included. There's a lot of money that web app makers are leaving on the table by not making "non cross platform pieces of software".
Hey, are you using that Swagger Importer? https://luckymarmot.com/paw/extensions/SwaggerImporter If it fails, I'm happy to help. Can you share with us the Swagger file you're trying to import (support@luckymarmot.com)? Will be happy to help.
(I'm the Paw founder)
Sorry for the trouble :( If you can, we'd love to hear more details about the bugs you had. You can contact us via our support page: https://luckymarmot.com/paw/support Thanks a lot!
Might be nice. However, I do not find video an acceptable medium for a tutorial or documentation. Might be easier to make than a written doc, but so much harder for the recipient to get value out of.
I use DHC and like it a lot. I tried a bunch of the other Chrome based HTTP testers and found it to be the easiest and neatest one. I haven't tried Postman yet though.
It would be nice if there was a way for it to tell I have donated though and stop bugging me.
A paw print is quite a generic thing and even the shape of the paw itself between the two is made differently. Aside from the general idea of a paw, they don't seem to have anything else in common.
After a decade or more of Mac apps working just fine through online sales, what is the driver - what is so significant - that makes you get so upset that it might not be offered on the MAS?
I personally find the move to the MAS a sad development - less $ per sale to the dev, 30% grift from Apple, as if they needed more money, and sandboxing that renders some of the best apps out there less-than-useful. Not to mention Apple's arbitrary approval process that - if nothing else - puts an additional week between me and bug fixes.
I can understand liking the convenience. But what makes it so necessary?
I'm the founder of Paw, and frankly I like the MAS. It gave Paw a lot of visibility without us taking any financial risk. Otherwise, we would have needed to pay for some kind of advertising when we didn't have the money for it. MAS allowed us to bootstrap and gain users.
Sure, the 30% split for Apple sounds like a lot, and it surely is. That's exacly why we encourage users to get Paw from our website (which uses Stripe for CC processing). Also, website purchases get updates a little faster, as it doesn't rely on Apple's approval (which is IMO the real pain point of the MAS).
Lastly, sandboxing isn't an issue at all for us. And the version distributed through the website is also sandboxed. I personally love sandboxing, as a user first, and as a developer too. Sure, some apps (due to their nature) can't work with sandboxing, and should probably be allowed on the MAS as a special exception (the example I have in mind is the excellent Git Tower).
It's good to have your view on this, but I honestly think you should make some reference to the MAS on your site - even if it's on a page that highlights the user downside (slower releases etc) - if I browse an app site/page and it doesn't mention the MAS I assume they're not on it.
I absolutely understand why developers don't like it - I wish Apple worked so they did so more stuff would be there. For me it's the sandboxing on small utility apps, and I admit I'll look in the store first. It's just peace of mind really, if an app doesn't need out the sandbox (I acknowledge many many apps do) then I'd rather have it contained.
See flashlight apps with absurd permissions and spyware on Android to see what assholes occasionally do with too many permissions.
> I can understand liking the convenience. But what makes it so necessary?
I said it makes me significantly less likely to buy it - specifically because of two factors: the convenience, and the security of knowing who is charging my card.
I didn't say "I won't buy this if it isn't in the MAS" - so what part of what I said means the MAS is "necessary"?
> I personally find the move to the MAS a sad development -
I didn't say everyone should be forced to use the MAS. Neither did Apple. Nothing stops a developer from releasing their App on their own and via MAS.
> less $ per sale to the dev, 30% grift from Apple, as if they needed more money
70% of $40 is less than 100% of $0?
> and sandboxing that renders some of the best apps out there less-than-useful.
Not to mention that pesky security it provides for end users.
Seriously, if an app can't operate within the sandboxing of the MAS, its completely reasonable for it to be not sold that way.
This app can operate within a sandbox, so why do you have such a problem with someone else wanting/using a more convenient and secure option?
That you know the charger of your card is the argument that resonates the most with me. That's fair, and a solid reason to use a processor like Stripe - recognizable and near normal processor fees.
> "70% of $40 is less than 100% of $0?"
This is a terrible, terrible argument for being shoehorned into giving up 30% of your revenue. Stripe (et. al) charge, say, $0.30 + 3%. Add in binary hosting fees and we're at 30%? Again, I understand the CC argument, but this is very much an argument about how I (or someone else) should appreciate your business in whatever form it comes to me, and that's not true. You'll probably want point releases and features and customer support, but for 30% less than a sustainable price.
(Note that I'm not allowed to charge 30% more on the MAS to pass on the cost... That's a violation of the MAS developer agreement.)
> That's fair, and a solid reason to use a processor like Stripe - recognizable and near normal processor fees.
As a user I don't get to choose which payment processor a developer uses.
> but this is very much an argument about how I (or someone else) should appreciate your business in whatever form it comes to me, and that's not true. You'll probably want point releases and features and customer support, but for 30% less than a sustainable price.
You're ignoring the higher likelihood of purchase via the MAS. When I can just click and its purchased without hassle, without issues, you have to deal with a lot less lost sales due to hard/troublesome/scary payment processes.
If you don't want to sell on the MAS, thats absolutely your choice as a developer, but you need to recognise that the MAS is a much better experience for buyers than pretty much any other option currently in use. The best case scenario is a seller who has an easy buying workflow, actually handles security correctly, uses a reliable payment processor, and gives me the required licensing information instantly.
I've not seen that very often, and even when I do, I'm still left having to manage my license information so I can easily re-install.
Obvious solution - put the app up on the mac app store at 30% or so higher cost, and keep it around on Stripe or similar for those who want to buy it for less. Seems win-win.
Apart from breaking the rules for MAS publishing it's also dishonest - it doesn't cost $0 to self-distribute, but no one ever itemises that cost as extra
Is having some kind of rebate coupon after buying from a different payment processor an option? Or maybe increasing the price by 30% all around, and then throwing in some sort of 'added extra' for people who don't buy through the MAS?
Also, I like the MAS even less after learning about this kind of terrible control.
Otoh with MAS you get: hosting, payment processing, easy notification of updates for the users.
As a user I love that when I get the new machine I don't need to go hunting for all the apps I own, looking for the download link again, then looking for the serial numbers/licences. I can just go to App Store app and click "Install".
Don't get me wrong, Paw is a really nice app, but I don't feel that it rivals the productivity of bash-jitsu for most day-to-day use.