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.
There have been many tickets opened (and closed) on this problem. Searching their issues for the keyword "offline" should bring up some of them. This one is just the latest.
For further context: I'm not sure if this has changed but at that time signing in seemed* to be required (there's some discussions in the ticket about confusion in the UI about this so in retrospect UX dark patterns were likely at play). However, while it may have been possible to make ad hoc requests without an account, it didn't seem to be possible to save request collections locally without sign in.
The original issues were from 2015 & 2017 - Scratchpad was only added to docs in Jun 2021 (before that was an undocumented feature for likely under 2 years I would guess).
Also, on the suitability of Scratchpad as a workaround for this bug, as quoted from person who created the linked issue:
> and no, scratchpad is not a solution to this.
The same sentiment is echoed through many of the more recent closed issues created in Github on this topic.
Either way: my comment above was mainly about dark patterns, which makes the existence of a workaround (not matter how suitable) somewhat moot. Even if this issue gets fixed "properly", the attitude of their devs over this long a period of time has been more than enough to turn me off using their software.
Scratchpad was specifically added as a feature to clearly allow people to use it Postman in an offline mode because otherwise people were confused about the distinction between an offline/online mode (Why is my content not showing up on Postman's web version for example). There are some features that just can't be developed with local storage as the only option.
An exceptionally large majority of users that give us feedback are pretty happy with the collaborative online features that we provide through Workspaces.
Unfortunately, a small but vocal minority is insistent that all those things be not developed because they have built their own workarounds through patterns from decades ago (CLIs, editors, repositories). I just don't agree with the sentiment that progress towards making lives easier for others should be stopped for a narrow viewpoint to be met. I also understand that it will lead to alternatives but so far almost everything that I have seen in the market has been a clone of our feature set - open source or closed source. I am happy to see people compete with new ideas.
> There are some features that just can't be developed with local storage as the only option
This is disingenuous. Firstly, no-one is asking for this "as the only option"; they're asking for it as an (exclusive) option. Secondly, there are no features being asked for here that can't be developed with local storage as an option - in fact, the default is for local storage to be the only option. In most apps, the approach is to add sync as an extra, not as the required default.
Scratchpad seems a perfect representation of the developers' motivations actually: it's both a demonstration that the feature is possible but deliberately implemented as a non-default side-feature without integration with the app's main workflows, to discourage use. So the devs can give it as a "solution" while continuing to pervasively track the bulk of their userbase.
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?)?
Can confirm. Unfortunately, Postman is too resource-hungry (on Ubuntu). Launching is taking a while as well.
I have to admit I'm quite surprised that VS Code (which is also an electron app) is relatively fast and resource-sensitive. Having open a few applications in my daily workflow, moderate resource consumption is getting an important selling point for me.
Oh, that's really unfortunate, I really like httpie. I wonder how long time it'll take for them to end up trying to extract as much value from each user as possible...
HTTPie founder here. These are valid concerns. There are two parts to this: 1/ What happens with HTTPie for Terminal, and 2/ how HTTPie for Web & Desktop and the overall platform will look like.
1/ HTTPie for Terminal will always be open-source and obviously free. The difference is that now we’re able to pay a talented developer to work on the project full-time (the recent 3.0 release is a result of that).
2/ We’re building a new platform with the same principles that made HTTPie for Terminal successful in mind: uncompromising simplicity, focus on productivity, and delightful user experience. We’re in the same space as Postman, but the idea is to be anything like. We’re striving to become what Linear is to Jira, Vercel to AWS, Figma to Adobe, etc. That is, to offer a much simpler and more focused product.
Premium services for companies will be a natural extension of the single-player mode, and all incentives will be aligned in a way that doesn’t cannibalize the core experience.
A lot depends on the founders. There's plenty VC funded, OSS-originated businesses that don't suck. GitLab comes to mind. There's no reason to immediately assume httpie is going to be the Postman story repeated, although I agree that with VC funding it's more likely than without.
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.
We own licenses for our developers too, and plan on buying more. Please, please, please, don't screw us over and change course later on. We really like Paw, and not being based on Electron is the major selling point :)
It seems unrealistic long term for any company to maintain one native app and an electron app across other platforms. Spotify did this for a while, but they eventually forced everyone onto the electron app. Something to keep in mind.
> It seems unrealistic long term for any company to maintain one native app and an electron app across other platforms
Not sure if it's more or less unrealistic to have one native app per platform.
> Spotify did this for a while, but they eventually forced everyone onto the electron app
I don't think (but someone correct me if I'm wrong please) Spotify has ever been a Electron app. If I recall correctly they are indeed embedding Chromium but they are doing their own custom binding (possibly via CEF), not via Electron.
Often apps don't have one app per platform, often it's just Mac or something. They get Electron so everyone can use it and then suddenly the Mac app has an equal number of users as Electron (or less) and then at that point justifying development becomes difficult.
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
It really needs some love in the UX department. There are so many icons and toolbars it is hard to understand where to find things or why they are placed where they are.
Same here. I am not sure where would I even use postman for. I essentially would wait 3-5 minutes to have postman initialized, be greeted with a dialogue box for an update or something, drop a json file for the headers and skim through the output.
But it takes seconds to get up and running with requests-html. And it can do anything Postman can do and more. I have no idea how people in organizations use postman though.
> I am not sure where would I even use postman for.
It's really handy for generating test suites to hand to people who don't necessarily have the skills to write Python / node / whatever code. Have worked at places where certain changes needed a Postman collection alongside for people to manually verify that it works.
(Also handy for un-coder people to make test suites, obvs.)
(Also handy as a quick-and-dirty "view this data via the API" when you don't yet have a web UI etc.)
I've worked in a place where test suites started in postman because of the lack of skill in QA.
For us, the fact that you end up writing "code" in postman meant it had a learning curve anyway, so it was a really short sighted win.
For everyone smart enough to write postman code, especially postman code that leverages the scripts and storing variables, a simple test project set up by a dev is going to be very worthwhile. Postman doesn't have a linter or compiler, and it doesn't enable easy viewing of changes in source control because it's just one big json file.
HTTPie for Web & Desktop is in private beta. We’re shipping updates weekly and inviting people from the waitlist every day. As soon as we’ve tackled the few remaining things on our roadmap and polished some rough edges, it’ll become publicly available.
I think the killer feature for these separate tools is usually that you can easily do a right click -> "copy as curl" in the network inspector, then import it in Postman/Paw and then tweak parameters / add headers there. This is not really possible in the browser network tools.
And then you accidentally refresh or close the tab and everything is gone. I usually use specific requests over many days if I'm reverse engineering something so having these available, sorted in folders for me is important. Of course for other uses cases it might be fine to have them live in the browser.
I just use the HTTP Client from IntelliJ/Rider. It's text only, you can use variables (for Auth for example), and I can copy/paste queries from Fiddler Classic/my browser or to colleagues.
> 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.