As I have also been frustrated with the direction Postman has taken, I have a great alternative to suggest, if the only thing you want to do is fire requests on demand easily and do not need automated testing.
Can it do substitution with some sort of application-based KV store? The main reason I used a rest client like Insomnia is so that I can reference secrets like {{ client_secret }} or {{ api_key }} and have a change to the value in the KV store reflect for every request.
I too like this approach, because the format is simple and text-based and you can maintain it in your git repository.
My main gripe with Postman and Insomnia isn't actually the web based UI, but the lock-in. You can't access the files that they store their data in easily. Postman especially tries to push people towards getting their per-seat 'cloud' subscription if you want to share sets of HTTP requests.
But using this text-based REST client, you don't have this file lock-in.
For IntelliJ this feature is actually built in, I believe it uses the same syntax.
Shameless plug: There's also Prestige at https://prestigemad.com, which is very similar but works right in the browser. You can save your files as Gists as well. Templating with variables is also supported with `${}` syntax, like Javascript's template strings.
But gRPC support is not built yet. It's on the roadmap.
Postman founder here. Thank you HN community for highlighting this feature. We have been seeing gRPC usage exploding especially in microservices driven architectures and we are looking forward to the feedback we get on the feature.
A few other observations on comments that I read through:
1. Postman leans towards adding UI affordances instead of hiding them. This can irritate experienced developers at times who already know the complexities of HTTP or other protocols but that is really how new developers find their way around. So while it is attractive to have 1000 options hidden behind a command line interface, nobody uses 995 of those features. We are getting better at building experiences for both experienced and new developers. Also, I don’t believe reading man pages of git or curl is a better experience.
2. Performance is a huge area for improvement. More to come in subsequent releases this year.
3. Our roadmap is community driven: https://github.com/postmanlabs/postman-app-support/issues. Raising more investment helps us do more. We have built a business model around doing the maximum for every developer on the planet while also providing value to companies so we can charge for it and continue development. I find it fair that companies spend hundreds of millions of dollars on salaries can pay some money for improving their productivity by spending in developer tools.
4. API Development is a huge and growing area and developers are spending more and more time working with APIs rather than their IDEs. API Design, documentation, and testing are areas that a large number of developers tell us they wish they had better tooling for. Most of their time is spend pointlessly in trying to figure out how an API works (in some cases whether an API even exists). We decided to take Postman in those areas even though paradoxically it might lead to “less” Postman usage. (The faster people figure out an API the fewer number of calls they have to send)
5. Finally, it is good to see here a call for fewer features which we insist internally as well. Unfortunately at some point some part of the community is upset that we are NOT adding features (just see the gRPC thread on our issue tracker!). We don’t see issues to remove features as much as we have requests to fulfill. We do remove features consciously but it is a hard problem, so we default to adding them slowly.
Postman is so incredibly bloated and slow these days. All I want is a REST client, but it feels like every time I want to perform a basic task now, I have to dig past all of their confusing platform and cloud stuff that I have no interest in.
To add another data point, I also moved on from Postman a while ago. Similarly to several commentors here I had found it to have become bloated, slow and buggy imho. In my particular use case, I found the urlencoding when using oauth1 to be pretty buggy. It would sometimes not work on certain headers it generated.
My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some team members are also using insomnia which doesn't seem to be much better in my opinion.
I recently found httpyac[1]. It's a cli and file based http client similar to the IntelliJ HTTP client, but has plugins, hooks and allows scripting through javascript blocks. It seems to have everything I need but I haven't used it much yet. It also already supports gRPC.
One of the issues I found with http clients I looked into is that they often don't provide enough functionality to hook into the request process. Either before or after a request is executed to add to the headers or parameters of the request or getting the results of the request. Postman did provide some of that but that's one area I wanted more from any client I looked at. I could of course simply wrap curl in a script but at that point, I will be maintaining my own jerryrigged version of an http client for my team.
I moved on to a system of Bash scripts checked into a company repo. Sounds silly, but it works. It's version controlled easily, you can refer to the scripts from documentation, and it's cross-platform.
Never heard of httpyac. Looks pretty nice. We've been using httpie, which works great, but it's missing nice-to-have stuff like graphql and oauth2, which I've had to build in myself.
> My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some team members are also using insomnia
One of the first things I learned working professionally is that of it’s possible you need to force all engineers to use the same OS. No one will ever agree on one Linux distro. No one wants to develop on Windows (unless you’re developing for Windows). So you should but everyone a MacBook. The time saved by reducing duplicated work in getting things working on your OS more than pays for the Apple tax. As for personal OS preference - get over it.
> some team members are also using insomnia which doesn't seem to be much better in my opinion.
In my experience Insomnia suffers from some of the same bugs that affect Postman[1], but at least they don't do the scummy things that Postman does, for example locking you out of your _personal_ Postman account if your ex employer forgets to pay their business subscription (if anyone at Postman is reading this: that's the reason I left and will never come back).
PS I swear that some time ago I saw that Paw was now available for Linux and Windows as well, but I just went to their website and it still says "exclusively built on macOS", I'm really confused now.
My main complaint is that it’s terrible at restoring local state. With sublime text I can just leave whatever I had opened and shut my computer down and it’ll be back to where I left it. With Postman the tabs will kind of be there but when you open one it just says it couldn’t do something or another and all the input data is gone.
I often have unsaved state because I’m testing a specific case that I don’t want to save
> One of the issues I found with http clients I looked into is that they often don't provide enough functionality to hook into the request process. Either before or after a request is executed to add to the headers or parameters of the request or getting the results of the request.
I find that httpkit (or just mitmproxy) often gives me decent insight to the actual requests.
I don't know about altering requests "in flight" - I typically re-issue the request via curl or my application server (eg: rails console or debugger breakpoint).
Strongly considering purchasing httpkit - but so far I've just needed it occasionally.
I feel like postman etc is closer to println Debugging, while just intercepting the traffic is more like using a real debugger. But I guess I can see why some like postman etc for exploration - so far i prefer swagger for that (or soapui for xml/soap - preferably running soapui under httpkit for the best of both worlds).
Thanks for sharing. Is the code for httpyac anywhere? I can only find the repo for the docs. I'm trying to check it out, but I encountered some errors when trying it add it as a global with yarn because I'm running a node version greater v14. The extension also gave me a deprecation warning about Buffer() usage.
It's built on a plugin architecture, does gRPC, GraphQL, JDBC, Ws, et.al. Other plugins allow sharing of workspaces to various services. Written in Java/JavaFX, brew or chocolatey install.
My company’s product is an API and Postman has been a key tool to test it, collaborate internally on requests and share it to the external world. Our ecosystem is also very API intensive and we also use Postman to discover other companies APIs.
We use all those features:
- HTTP requests
- Mock servers (to test async requests which call back a webhook endpoint)
- Workspaces: private and public
- Monitors, alerts and integrations
I’m excited by the direction Postman has been taking over the years.
Most of commenters in the thread seem to think that Postman is still in the “lightweight cURL replacement GUI” market, like so many of the alternatives mentioned. I think this is wrong - Postman has now has moved to an upper market where requirements are more advanced and complex.
I've been using gRPCurl for years and, once you understand gRPC and Protobuf, it's pretty easy to use and can be scripted in many ways - https://github.com/fullstorydev/grpcurl.
I've been using https://github.com/fullstorydev/grpcui + Paw so I hope that Paw catches up and also adds gRPC support. Definitely a good decision to have everything in one tool.
I've posted this in a reply comment but here's a top level comment as well.
The main reason I dislike Postman is not actually the web based interface, but the fact it keeps its data files to itself to try and push teams to using their cloud offerings.
If a HTTP client stores its requests and configuration as a plain text file, it becomes really easy to manage it alongside a codebase and share between teams. But alas.
That said, I have seen a paid version of postman be used in a company and it worked really well. But it's an expense.
An alternative is what is mentioned in the top comment at this time, VS Code's Rest Client or Intellij's built-in rest client, which use plain text files (.http files) with plain text based HTTP request definitions. Those can be executed directly, without hidden functionality, and stored / updated / diffed in git.
Another alternative - but this is restricted to HTTP based APIs - is Swagger/OpenAPI combined with Swagger-UI, which is both a documentation page and a demo page. The UX isn't the best, but it works very well imo.
I used to like Postman, when it was a simple browser extension. I basically used it as a curl gui.
Now
> Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.
I guess I’m no longer their target user. Back to curl/httpie.
I used to like Postman until it locked me out of my locally-stored data while I was offline (testing my own applications on localhost) for an extended period , I found out that it phones home constantly (cannot be disabled) & locks you out if it fails. The developers stating they had no intention of changing this for "security reasons" before closing the Github issue sealed the deal.
It is also buggy, resource hog and instable. I use it on Ubuntu and os x m1 and I often have to kill it because it stops accepting any inputs or it ate all memory (and cpu after that when you click anything). Hoppscotsch and others are better now: I guess they wanted way too much too fast (I did not check but I suppose they got VC money?)?
I'm building a desktop app that lets you query HTTP APIs but also databases and files. So definitely something you can use as a simple curl GUI. The big benefit of this tool though is that you can script and graph results as well.
Paw[0] is a pretty good native macOS option, at least for now. They were acquired sometime last year by RapidAPI[1], and since have released electron based versions of their app for Linux and Windows.
I’m really hoping they don’t go the 1Password route and kill their native macOS product to move everyone to the cross-platform one.
I wonder how much of that was driven by the silicon valley VC culture. You won't get funding if you don't show growth and "innovation", which means catering to all kinds of users resulting into a bloated product with lots of bells and whistles.
The UX has gotten noticeably worse for me. Maybe I'm using it wrong, but now you have to setup a project and name things before you can actually start issuing requests.
And I found the whole experience a bit confusing in terms of user flow
On a related note, I'm wondering if there are plans for updating httpbin. The httpbin repo was transferred to the Postman organization somewhere between January and March of 2019 [1]. The last commit was made on November 2018 [2] and it's currently suffering from outdated Python dependencies.
I'v really had it with Postman. I don't get the priorities. Slow and sometimes confusing and auto-saving the configuration is still impossible(!) and I just keep loosing % of work done every single day. [0]
Glad to see lots of comment with alternatives here.
Left Postman a long time ago after all the stupid decisions. Never looked back. gRPC is a nice addition to Postman though. In contrary to what advocates of gRPC thinks, this kind of development is the key thing to bring gRPC to the wide audience. The lack of test tools for non-developers has been an obvious problem with gRPC. Most people should probably still not use gRPC since it is in most cases useless and causes a lot of problems.
As someone who is about to start a big project with gRPC kind of at the middle of it all would you mind elaborating on the other problems you were alluding to? From the outside and some basic testing it seems great
Good to hear. I became frustrated with the gRPC debugging experience recently, so I wrote GrpcBrowser, an extension for .NET apps that adds a swagger-like web UI: https://github.com/thomaswormald/grpc-browser
I've tried Postman quite a few times in the past - but for my use cases of exercising APIs or doing ad-hoc automation, it's always been much less frustrating to reach for a Jupyter notebook with the 'requests' library.
In the end it also leaves me with a git'able artifact to share with others.
If anyone is looking for a gRPC client which will automatically resolve imports between protos and also render structured input fields for each message, check out Protocall (https://protocall.dev - disclaimer, I'm the author).
I built it to solve my biggest pain points with existing tooling like BloomRPC and gRPCurl - they were difficult to use for anything more complicated than "Hello, World". I also couldn't find any tools that would let me send protobuf-encoded requests via HTTP/1.1 rather than gRPC - there are a couple options now, but as far as I know none of them support both that and gRPC.
[+] [-] avel|4 years ago|reply
The VS Code Rest Client extension https://marketplace.visualstudio.com/items?itemName=humao.re... is great for testing and debugging APIs.
You create a "my_request.http" file that contains something like
First line is the method and url, then headers, then a newline, then the request body.Hit ctrl+alt+p, the request is sent and you see the response in a side pane. Everything is encoded and decoded properly.
You can organize your tests under multiple files and folders.
I cannot recommend this extension enough, it has made my life so much easier.
[+] [-] judge2020|4 years ago|reply
[+] [-] avel|4 years ago|reply
[+] [-] Cthulhu_|4 years ago|reply
My main gripe with Postman and Insomnia isn't actually the web based UI, but the lock-in. You can't access the files that they store their data in easily. Postman especially tries to push people towards getting their per-seat 'cloud' subscription if you want to share sets of HTTP requests.
But using this text-based REST client, you don't have this file lock-in.
For IntelliJ this feature is actually built in, I believe it uses the same syntax.
[+] [-] sharat87|4 years ago|reply
But gRPC support is not built yet. It's on the roadmap.
[+] [-] seanw444|4 years ago|reply
Super straightforward.
[+] [-] nichos|4 years ago|reply
Which is an open source, cross platform alternative to postman.
[+] [-] saikatsg|4 years ago|reply
[+] [-] halpert|4 years ago|reply
[+] [-] a85|4 years ago|reply
A few other observations on comments that I read through:
1. Postman leans towards adding UI affordances instead of hiding them. This can irritate experienced developers at times who already know the complexities of HTTP or other protocols but that is really how new developers find their way around. So while it is attractive to have 1000 options hidden behind a command line interface, nobody uses 995 of those features. We are getting better at building experiences for both experienced and new developers. Also, I don’t believe reading man pages of git or curl is a better experience.
2. Performance is a huge area for improvement. More to come in subsequent releases this year.
3. Our roadmap is community driven: https://github.com/postmanlabs/postman-app-support/issues. Raising more investment helps us do more. We have built a business model around doing the maximum for every developer on the planet while also providing value to companies so we can charge for it and continue development. I find it fair that companies spend hundreds of millions of dollars on salaries can pay some money for improving their productivity by spending in developer tools.
4. API Development is a huge and growing area and developers are spending more and more time working with APIs rather than their IDEs. API Design, documentation, and testing are areas that a large number of developers tell us they wish they had better tooling for. Most of their time is spend pointlessly in trying to figure out how an API works (in some cases whether an API even exists). We decided to take Postman in those areas even though paradoxically it might lead to “less” Postman usage. (The faster people figure out an API the fewer number of calls they have to send)
5. Finally, it is good to see here a call for fewer features which we insist internally as well. Unfortunately at some point some part of the community is upset that we are NOT adding features (just see the gRPC thread on our issue tracker!). We don’t see issues to remove features as much as we have requests to fulfill. We do remove features consciously but it is a hard problem, so we default to adding them slowly.
[+] [-] hbn|4 years ago|reply
[+] [-] jonfk|4 years ago|reply
My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some team members are also using insomnia which doesn't seem to be much better in my opinion.
I recently found httpyac[1]. It's a cli and file based http client similar to the IntelliJ HTTP client, but has plugins, hooks and allows scripting through javascript blocks. It seems to have everything I need but I haven't used it much yet. It also already supports gRPC.
One of the issues I found with http clients I looked into is that they often don't provide enough functionality to hook into the request process. Either before or after a request is executed to add to the headers or parameters of the request or getting the results of the request. Postman did provide some of that but that's one area I wanted more from any client I looked at. I could of course simply wrap curl in a script but at that point, I will be maintaining my own jerryrigged version of an http client for my team.
[1]: https://httpyac.github.io/
[+] [-] binwiederhier|4 years ago|reply
https://www.jetbrains.com/help/idea/http-client-in-product-c...
https://www.jetbrains.com/help/idea/exploring-http-syntax.ht...
[+] [-] pkulak|4 years ago|reply
Never heard of httpyac. Looks pretty nice. We've been using httpie, which works great, but it's missing nice-to-have stuff like graphql and oauth2, which I've had to build in myself.
[+] [-] teaearlgraycold|4 years ago|reply
One of the first things I learned working professionally is that of it’s possible you need to force all engineers to use the same OS. No one will ever agree on one Linux distro. No one wants to develop on Windows (unless you’re developing for Windows). So you should but everyone a MacBook. The time saved by reducing duplicated work in getting things working on your OS more than pays for the Apple tax. As for personal OS preference - get over it.
[+] [-] rattray|4 years ago|reply
Personally I like the VSCode REST Client best: https://marketplace.visualstudio.com/items?itemName=humao.re...
[+] [-] mastazi|4 years ago|reply
In my experience Insomnia suffers from some of the same bugs that affect Postman[1], but at least they don't do the scummy things that Postman does, for example locking you out of your _personal_ Postman account if your ex employer forgets to pay their business subscription (if anyone at Postman is reading this: that's the reason I left and will never come back).
PS I swear that some time ago I saw that Paw was now available for Linux and Windows as well, but I just went to their website and it still says "exclusively built on macOS", I'm really confused now.
[1] e.g.both Postman and Insomnia break when you import multiple API keys https://swagger.io/docs/specification/authentication/api-key...
[+] [-] redisman|4 years ago|reply
I often have unsaved state because I’m testing a specific case that I don’t want to save
[+] [-] e12e|4 years ago|reply
I find that httpkit (or just mitmproxy) often gives me decent insight to the actual requests.
I don't know about altering requests "in flight" - I typically re-issue the request via curl or my application server (eg: rails console or debugger breakpoint).
Strongly considering purchasing httpkit - but so far I've just needed it occasionally.
I feel like postman etc is closer to println Debugging, while just intercepting the traffic is more like using a real debugger. But I guess I can see why some like postman etc for exploration - so far i prefer swagger for that (or soapui for xml/soap - preferably running soapui under httpkit for the best of both worlds).
https://httptoolkit.tech/
[+] [-] CSSer|4 years ago|reply
[+] [-] tpoindex|4 years ago|reply
It's built on a plugin architecture, does gRPC, GraphQL, JDBC, Ws, et.al. Other plugins allow sharing of workspaces to various services. Written in Java/JavaFX, brew or chocolatey install.
[+] [-] panabee|4 years ago|reply
[+] [-] ynouri|4 years ago|reply
We use all those features:
- HTTP requests
- Mock servers (to test async requests which call back a webhook endpoint)
- Workspaces: private and public
- Monitors, alerts and integrations
I’m excited by the direction Postman has been taking over the years.
Most of commenters in the thread seem to think that Postman is still in the “lightweight cURL replacement GUI” market, like so many of the alternatives mentioned. I think this is wrong - Postman has now has moved to an upper market where requirements are more advanced and complex.
Btw - we use both Postman & cURL
[+] [-] lysium|4 years ago|reply
Plus, if the API moves, we had to (manually) find and fix dozens of Postman tests.
I'd appreciate it, if you have some insights that can move my team forward.
[+] [-] smoyer|4 years ago|reply
[+] [-] mythz|4 years ago|reply
As a consequence of our API Design we're also able to reuse our existing Typed APIs in gRPC services: https://docs.servicestack.net/grpc
[+] [-] shp0ngle|4 years ago|reply
on one hand, it has all these really great features. I would be half as productive without it.
on the other hand, it’s so, so annoying with all these updates and cloud features and something or other all the time :(
[+] [-] liyasthomas|4 years ago|reply
Web app: https://hoppscotch.io
GitHub: https://GitHub.com/hoppscotch/hoppscotch
[+] [-] dewey|4 years ago|reply
[+] [-] Cthulhu_|4 years ago|reply
The main reason I dislike Postman is not actually the web based interface, but the fact it keeps its data files to itself to try and push teams to using their cloud offerings.
If a HTTP client stores its requests and configuration as a plain text file, it becomes really easy to manage it alongside a codebase and share between teams. But alas.
That said, I have seen a paid version of postman be used in a company and it worked really well. But it's an expense.
An alternative is what is mentioned in the top comment at this time, VS Code's Rest Client or Intellij's built-in rest client, which use plain text files (.http files) with plain text based HTTP request definitions. Those can be executed directly, without hidden functionality, and stored / updated / diffed in git.
Another alternative - but this is restricted to HTTP based APIs - is Swagger/OpenAPI combined with Swagger-UI, which is both a documentation page and a demo page. The UX isn't the best, but it works very well imo.
[+] [-] paozac|4 years ago|reply
> Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.
I guess I’m no longer their target user. Back to curl/httpie.
[+] [-] lucideer|4 years ago|reply
[+] [-] tluyben2|4 years ago|reply
[+] [-] BiteCode_dev|4 years ago|reply
[+] [-] eatonphil|4 years ago|reply
Always happy for any feedback!
https://github.com/multiprocessio/datastation
[+] [-] chin7an|4 years ago|reply
I’m really hoping they don’t go the 1Password route and kill their native macOS product to move everyone to the cross-platform one.
[0] https://paw.cloud/ [1] https://rapidapi.com/
[+] [-] robofanatic|4 years ago|reply
[+] [-] adam_arthur|4 years ago|reply
And I found the whole experience a bit confusing in terms of user flow
[+] [-] soraminazuki|4 years ago|reply
[1]: https://web.archive.org/web/20190322170311/https://github.co...
[2]: https://github.com/postmanlabs/httpbin
[+] [-] a85|4 years ago|reply
[+] [-] sorahn|4 years ago|reply
Very excited to try this out.
[+] [-] thcyron|4 years ago|reply
[+] [-] karolsputo|4 years ago|reply
Glad to see lots of comment with alternatives here.
[0] https://github.com/postmanlabs/postman-app-support/issues/81...
[+] [-] AtNightWeCode|4 years ago|reply
[+] [-] mhoad|4 years ago|reply
[+] [-] thomaswormald|4 years ago|reply
[+] [-] Nihilartikel|4 years ago|reply
In the end it also leaves me with a git'able artifact to share with others.
[+] [-] newusertoday|4 years ago|reply
It lets you write the api, test it and generate the documentation all from the same source of truth file.
[+] [-] federicotdn|4 years ago|reply
[+] [-] ProtocallDev|4 years ago|reply
I built it to solve my biggest pain points with existing tooling like BloomRPC and gRPCurl - they were difficult to use for anything more complicated than "Hello, World". I also couldn't find any tools that would let me send protobuf-encoded requests via HTTP/1.1 rather than gRPC - there are a couple options now, but as far as I know none of them support both that and gRPC.