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

A comment like this is precisely why I come to HN. This product looks amazing.

It is WELL worth the $50, or $9/month on a team subscription plan

Not saying it's necessarily easier or better, but I tend to end up doing such things in Bash with curl/wget and jq: https://stedolan.github.io/jq/

I had no idea you could chain requests in Paw! Thanks for sharing that useful tidbit.

Coming soon... ;)

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.

Postman can do that too, albeit in a hacky way. https://www.getpostman.com/docs/chaining_requests

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.

Check out how our chaining and env vars work. We have Swagger import too. https://www.runscope.com/docs/api-testing

If you're trying to import Postman collections into Paw, that's easy https://paw.cloud/docs/migrate/postman (all requests, grouping, environment variables, etc. will be preserved). Once imported, you can even generate a Swagger https://paw.cloud/extensions/SwaggerGenerator