Paw: The ultimate REST client for Mac
luckymarmot.com
luckymarmot.com
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.
Full disclosure: I interned with Postman for a short duration last year.
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.
Disclaimer: I'm the founder of Paw.
Can it compare a response to a previously saved response? That would be handy for looking for regressions when refactoring the code behind an API.
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/
Go Twins!
You can do a whole slew of functional tests and as a bonus you can use those same tests for monitoring if you want.
Are you planning to go more native with something like Atom's Electron platform?
And yes, native apps are coming soon! Atom's Electron is a strong contender. We are exploring all possible options. :)
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.
I love it.
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 :-)
This just might be, and it'll write the curl command for you too :)
https://metacpan.org/release/App-RecordStream
https://metacpan.org/pod/App::RecordStream::Manual::Story
https://metacpan.org/pod/App::RecordStream::Manual::Examples
curl command lines can get huge and unwieldy. If a curl command has a huge amount of input, that gets unwieldy, too. Same thing with data input.
The fact that your requests persist and can be repeated and modified is useful. Better than looking up past commands in ~/.bash_history.
Quite a few of the Windows users in my office are jealous of this particular application.
- 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.
The positive side is the capturing of HTTP requests in Chrome.
Slowly migrating to Postman https://www.getpostman.com/
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.
Postman has no problems with it though :)
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.
I also like the 'environment variable' feature. I can easy test the API locally and on staging server just by changing setting different environments.
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?
And REST is just an HTTP based architecture.
> A REST API should not be dependent on any single communication protocol
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
Doesn't matter. Real world usage defines words, not original intended meaning or etymology.
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?
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.
[1] https://muse.jhu.edu/login?auth=0&type=summary&url=/journals...
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!
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.
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.
That is, the important parts people care about.
Disclaimer: I'm a Paw guy (founder).
Postman has these type of import options: https://dl.dropboxusercontent.com/spa/4moihw0kt47f2sy/lona1q...
I also tried saving my Swagger JSON spec to a file and importing it via the Swagger Importer, but it failed. =\
Otherwise, it seems gorgeous!
It would be nice if there was a way for it to tell I have donated though and stop bugging me.
In my honest opinion, it is the very worst computer program to have ever walked the earth.
Edit: apparently it is available via MAS but there is ZERO mention of this on the site (on mobile at least).
(Not my app, by the way.)
That said, it is in the Mac App Store.
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 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?
> "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.)
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.
Also, I like the MAS even less after learning about this kind of terrible control.
See flashlight apps with absurd permissions and spyware on Android to see what assholes occasionally do with too many permissions.
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).