Paw – Advanced API tool for Mac

Paw is engineered by a top notch team in France. They care about quality and details. We at Mashape have partnered with them in the past and they are super responsive and always focused on the best experience for the developer.

I'm a pretty heavy RESTful API user (feels like what I spend most of my day doing a lot of times), a pretty heavy Paw user and pretty well versed with its feature set, and on the CLI side, curl | jq. So I think I can actually probably answer this pretty well.

Paw helps me compose arbitrary calls faster. It also helps me just keep track of and search API calls really easily, just by searching the request list. I have an API call right there, with the JSON body, and I don't have to pull up the API docs. It's just way better than having a bunch of little shell scripts for these API calls, and better than having a big, ugly, stupid text file full of API calls, because I can execute them, and it really helps in composing them.

It just helps with a lot of little random stuff. Like, if you tell it you're doing a JSON-body form post, and you've got quote marks in there, it'll get those quotes escaped right to get it embedded in the JSON.

If you're a heavy RESTful API user, I'd say just give it a try for a month and see if you feel like it's worth it. I thought it was.

There's command history, and if you're executing calls multiple times in a row and might want to see what changed between them later, the history is great. You can scroll back in your terminal, sure, but you tend to close terminal windows and lose the output. It just keeps everything glued together, it's really much more coherent than trying to throw around a lot of disparate API calls in a terminal with curl (or httpie.)

That being said, I do find it to be complementary to curl | jq. For one, the "keypath" filter in the http exchange pane of Paw doesn't take anything close to a full jq-like syntax. I pretty frequently use the "curl" code generator (it's got an httpie code generator as well, but it doesn't seem that one is as good at shell-quoting edge cases. Not sure who maintains that extension and if it's open-source, but if you love it, you might be able to help fix it if it interferes with your workflow) to copy out the call I composed, and even executed in Paw, so that I can do some jq mangling. (Or i could just copy out the json body if I didn't want to re-execute the call.)

If slinging RESTful API calls is a significant part of your day, you're almost certainly going to find value in something like Paw. It's got a 1 month free trial. I tried it, and didn't really plan to buy it, but a month ended, and I was using it and liked it.

I agree, before I buy software or start using something I will search on HN for threads like this to see what criticisms others have and what alternatives other people use. Many times I will find something with the same features but cheaper or open source.

If people stopped making comments recommending alternatives, similar things, and criticisms I probably wouldn't even look at the comments. I don't know if other people use HN like this, but it's the main reason the comments on here are valuable for me.

As the founder of Paw, I'm certainly biased, so I'll stick to the facts. Paw has "dynamic values" which lets you inline computed components in any field of your request: useful for pointing to values from other requests, previous responses (parsing is done on the fly, no need to refresh), which is useful if you want to send back an auth token returned by a previous request. Dynamic values can do also stuff like MD5/SHA hashes, HMAC, URL/hex/base64 encode, timestamps, randomizers (Chance.js, JSON schema faker) with no code required (you can write custom JS snippets too if ever needed). For example, we once demo'ed the Algolia guys that their custom HMAC-based signature for client-side search was doable with no code. So, if you have the need, you can do custom stuff easily.

Also, extensions (many are built by users) are bringing lots of extra features we would have not thought about ourselves: https://paw.cloud/extensions/

Environment variables in Paw can be nested or computed (with "dynamic values" described above). It can be useful, for example, to have an "Auth" variable that contains a pointer that accesses the "user.access_token" JSON path from inside the latest Login request, so you can later simply point to the "Auth" variable everywhere else. One other thing about envs, is that you can have independent groups of environments: a typical example is you have a "Server" group with envs called "Prod", "Staging", "Local" and independently a setup with user credentials or variables that are more like static globals (AWS Keys, etc.)…

Now regarding to the team syncing service, "Paw for Teams". It has branches, snapshots and full history. In a dev team, it means one dev can experiment stuff on the schema for API v2 while others are fixing bugs on API v1, and when API v2 is ready they can seamlessly merge the new updates back to the v1 branch. Also, we've made the choice not to be real-time synced, because it doesn't fit well to software development: when I'm experimenting stuff with an API I don't want others to be polluted by my temporary garbage. So instead you "commit" changes only when ready. More about Teams here: https://paw.cloud/teams

Last but not least, Paw locally encrypts with a randomly generated symmetric passphrase all credentials you enter in your projects, that means your server keys, access tokens, etc. are a lot safer. And now that you can (optionally) sync with Paw's backend, we certainly don't want to have your secrets in cleartext on our infra. As passphrases are never uploaded (obviously! but by default stored in OS X Keychain), it's the users responsibility to safeguard them and share them with their team (on 1Password or similar).

Extension APIs mostly are a minus. It's mostly used as an excuse for not shipping features.