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.
"We support two types of variables, one is Custom Variables which is defined by user and can be further divided into Environment Variables, File Variables and Request Variables, the other is System Variables which is a predefined set of variables out-of-box."
However, what I can't figure out is if it supports programmatic variable setting. I have an API where I need to retrieve a token from an endpoint before using it for every other endpoint, and I'm using Postman's test scripts to set that token as an environment variable before sending all the other requests so they can all use it. I don't see a way to replicate that with this extension.
Hi, one of the maintainer of Hurl [1].
It is effectively basically just curl (we're using libcurl under the hood). I would say that we have added the ability to chain request (you could use curl in a shell script), and a bunch of assert (like jsonpath, xpath etc...) on response (which you could arguably do also with shell script).
We also wanted something text based, that could easily be integrated in a CI [2] for instance. We are using Hurl to test our web application (~2M unique visitors/month).
Very happy with it currently, but there are really a lot of very good tools in this space (as we can see in these comments).
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.
Sounds a lot easier than curl tbh. No need to deal with shell scripts and their insane quoting, plus you get the response straight in your editor with syntax highlighting.
Maybe it’s just me but I’ve never had those issues. Another benefit of curl is that you have an easily searchable history of every command you’ve run. So you can easily find old invocations and rerun them.
How complicated are your requests? If I need to test a POST request with a JSON payload longer than a line or two, I'll go and construct my curl command in a text editor anyway, since the shell prompt / readline is not easy to edit. Once you need to start escaping single or double quotes or html payloads in the request, it quickly gets cumbersome. At that point I ditch the shell as a middleman and use the editor to submit the request for me.
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.
Are you planning on supporting importing the proto .bin format that stores file descriptors? This is the output of the proto compiler and would make it easier to provide a full transitive closure of deps for people who have complex build phases. You could also make a bazel rule set for exposing `bazel run //service/proto:postman` with default configs.
The nice part of the `.bin` format is you don't need to do anything to support multiple files or cross deps. The build system packages all of the files/messages/services into a single file for you to load.
Not as of now unfortunately. It is very hard to maintain multiple codebases that basically do the same thing. It is doubly hard for software that is supposed to validate other software because as solving every bug becomes a nightmare. We are focused on bringing a near-native experience on Windows and macOS this year though with better keybindings and UI layer integrations with the OS.
That said, we are looking into iOS and mobile devices right now - a smaller problem set before we look into native clients.
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.
It's golang + gtk so it uses 30MB of ram. I've made a website https://probster.com with some screenshots. I plan on making a barebones version available for download soon for all platforms, just gotta get around to it because I don't have a lot of experience with delivering desktop apps.
love the idea! i'd be willing to contribute but i'm sort of useless when it comes to go... i do have a suggestion though! lots of open source projects also use open collective [1] to crowd source funds, so if you want to add another payment method for users like me that don't have patreon that might be something to look into.
Thank you, if you want to help me out let me know :). I'll look into it, it's more along the lines of patreon/similar being a way to gauge interest and not a way to live off developing it right now.
If you would like an alternative that is still GUI, I personally switched from Postman to Insomnia (https://insomnia.rest/) in the last year and haven't looked back. It has been acquired recently, but it's still open source and very lean. Definitely recommend, you can even directly import your Postman collections if you used them.
To make things even worse I also recently (v. 9.11.0) found Postman process hanging on in my memory after I close it. This behavior isn't bad on its own, the problem is that after few days (of not using the app at all) it ended up eating 10% of my CPU time.
Since killing the process manually after using the app isn't the experience I want to have when dealing with simple tool I ended up testing some alternatives.
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.
The IntelliJ http client is absolutely brilliant. I love that using it is just editing a text file. Even if I didn't use everything else in IDEA, it would be worth it to fire up the IDE just for http scratch spaces.
Yeah I stumbled on this just the other day as well when reading about another IDE from JetBrains (I've been a paying IDEA customer for years). I'm looking forward to checking this out the next time I need to test HTTP endpoints. Postman has been decent for my needs but I always found some basic stuff to me way more difficult than it should be. The scripting in IDEA is something I'm very interested in. Postman had some of that but was more difficult that it should have been IMHO. Also I really like the idea of all my requests being text-based and something I can just commit alongside my code.
Devs at our company predominantly use IntelliJ's builtin HTTP client. I think I've only seen QA engineers use Postman because they don't have developer IDEs installed.
Vscode has an http_client module that's very similar to intellij's as well. Practically the only thing you've gotta change is how requests are saved to variables
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.
> 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.
Why stop there? You may also deny engineers admin access so they can't install unauthorized software alternatives to the one true path(tm). The policy is really solidified by not revising the list of blessed software for many years[1], assuring there are no support tickets, and your stack is truly 'stable'. Why let software engineers choose which software they'd like to install?
1. Eclipse is on the list, always has. Jetbrains requires skip-level approval as support is still experimental. What is VSCode? No one knows the process of adding it to the approved packages.
> 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.
We face a similar situation and we sometimes introduce API changes that break the monitors, which then requires to manually fix the testing script. The pain hasn’t been big enough yet to make us search for a different solution. Note that we are using Monitors mostly for end to end, user like tests, which represents a small fraction when compared to our unit test suite covering the API (where tests tend to be quite E2E as well).
We do use the one way Postman -> Github integration though. Every time a change is done, it is committed to a dedicated Github repo. We use it as a backup in case anybody messes up the scripts
We introduced two-way sync with GitHub, GitLab, BitBucket etc recently so you can keep your Postman collections inside version control while being able to work with them inside Workspaces. Details here: https://blog.postman.com/the-reimagined-api-first-workflow-f...
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.
This seems to be the golden way of solving the problem Postman is attempting to solve. Have your request collection as code that you can develop with your features and check into your VCS.
I always dreamed of something like this and was more than surprised that it doesn't seem to exist. Does anyone know of a similar solution for node.js?
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.
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.
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.
Server streaming, though I'm not sure how representative we are. We have servers that use streaming for watching for real-time changes. Currently using BloomRPC, if that helps
Grip looks super cool - it's one of the few other clients I've seen that will render structured input fields to make it easier to construct complex messages.
If you have a more urgent need for server-side streaming support, you could also check out Protocall (https://protocall.dev - disclaimer, I'm the author) - it supports all four rpc types (Unary as well as Client/Server/Bidirectional streaming), along with the structured input field rendering and automatic import resolution (via Github repo import).
I wrote it because existing tooling like BloomRPC and gRPCurl were difficult to use for anything more complicated than "Hello, World". I was also looking for tools that would let me send protobuf-encoded requests via HTTP/1.1 rather than gRPC, which didn't seem to exist at the time.
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
If you can be flexible about the infrastructure there is no problem with gRPC. Most problems I have seen is that is does not work or perform as well through proxies and load balancers without tweaking.
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.
A few days ago I wrote about using the Postman API to automate functional tests. To send HTTP requests, you use the HTTP API, which is built in Postman. To interact with some API’s, you need to make a call with one of the REST API’s that are built in. There are a few pre-requisites that need to be set up to make use of the HTTP/2 protocol and also ensure your application will be compatible with HTTP/2 in general. At times, especially when working on Android, it can be hard to test and debug a gRPC server. Luckily, gRPC supports a protocol called “stub” that will emulate the behaviour of your service when being tested.
This (grpc support) might change my mind but I’ve never found the need for a tool like postman for rest apis. curl + shell history search has worked pretty well. It’s so easy to share a snippet; to tweak it so you can make it as verbose as you need. It’s easy to run locally or on a remote machine.I guess if Postman has an easy way of sharing that might be great but it’s the stability of curl that makes it super appealing.
I see people complaining about what postman has become, but I never really saw the need for it to begin with.
When I'm exploring a new API I just do it in jupyter with python/requests. This way, when I figure out how to do what I want I already have some working code. I can see how this workflow would be a pain in a static language, but for dynamic languages I don't understand why more people don't do it this way.
Yeah the real value of Postman for me is that often times other teams will have postman collections that you can just import and explore an api with. Not that I really like what Postman itself has become though.
No love for burp[0] here? I really like it.. It's technically a security research tool (and thus, hilariously frustrating to try and get approved by the desktop people at say, a bank) and the UI is a bit old school, but it's never once annoyed me..
Shameless plug, as I'm one of the creators:
Kreya is (in our opinion) the most powerful gRPC GUI client out there, but the UI is not as overloaded as the Postman one. REST support and scripting/test integration coming soon as well!
I like is Apache JMeter, more for load testing but it can be used to get all the same information as all the other tools people are mentioning. https://jmeter.apache.org/
I just started using postman, because I'm working with a team that runs some tests with it. I've been unpleasantly surprised with the interface, it feels very slow and bloated on my fast dev machine.
Before you go down this rabbit hole I'd recommend quickly doing a POC microbenchmark, with a sample payload, against formats with schema to get an idea of why this isn't more popular:
- JSON (without schema) vs Protobuf (with schema)
- Msgpack (without schema, compressed) vs Protobuf (with schema)
- JSON + gzip or brotli encoding vs Protobuf + gzip or brotli
- JSON + gzip or brotli encoding vs Msgpack + gzip or brotli
Compression will erase a lot of the gains even with a schema-defined protocol, but if your goal is low CPU (just serialization) then msgpack is usually good enough.
Learn bash scripting and you will hate yourself every day for having to wade through terrible language decisions made >30yrs ago while having to do everything by yourself because nobody else at your company knows Bash while also having no opportunities for advancement because nobody understands what you do and why it's important.
I have a meta question to ask, in threads like these where big products announce new features or big funding I always see commentors lamenting bloated software or it having too many features, not doing the one simple thing you want it to do, etc.
To me it seems the only trajectory of developers building products is to add new features, its how we justify keeping ourselves around most of the time. So what my question is is how do you actually expect products to just stop active feature development? Or would you rather a second standalone app to install?
I'm a relatively young developer so I'm hoping to gain some insight from this mindset I see all too often.
What I’ve noticed is that developers are incredibly annoyed when their tools don’t work well. Developers use their tools a lot, and when a tool starts “misbehaving” (resource hungry, sporadic failure, non ergonomic design etc) they are exposed to that failure constantly. This constant exposure can create intense feelings (either love or hatred) and nowhere to express them, so it will spill out on slack and on HN threads (eg count yourself lucky if you’ve worked somewhere that nobody has ranted about terraform).
So take these criticisms with a grain of salt. The creators of tools and the users aren’t always aligned on the most important thing to do next and you only have so much money and time to execute on as a company so you have to make trade offs.
Terraform's error messages for things it has control over are incredibly precise. It does not have control over the content of errors are returned by provider APIs, and they are often very vague.
This is solved in food products by differentiation. Someone likes the no pulp orange juice so they buy that and someone else likes the stuff with pulp in it so they buy that.
Why not do the same thing with software?
Release 10 different flavors of Microsoft Word and let people choose the one they want.
This sounds like a really bad idea. With orange juice it takes less than 30 seconds to differentiate the versions. If this was done with something like Microsoft Word you would probably have to spend the better part of a day teasing out exactly which features you needed or wanted. I think a semi relevant modern example would be how the release of hitman 3 worked out. They had to make a flow chart of how to buy the right copy of the game with the features you wanted.
> They had to make a flow chart of how to buy the right copy of the game with the features you wanted
"They" makes it sound like IO Interactive (developers and publisher of Hitman) made that flow chart for people to use, but in reality it's community made by someone from Reddit.
And to be honest, it doesn't seem that complicated, seems like a joke flow chart to make it more complicated than what it is. These editions seems to exists (for the record, I have neither and first time I hear about them):
- Trilogy Premium Add-ons Bundle
- Trilogy Edition
- Standard Edition
- Deluxe Edition
- A DLC
Trilogy obviously is about the full series (1 to 3), and Deluxe edition contains "Deluxe Pack". Which one you want? Ok, want the DLC too? Ok.
People only use 10% of word, but this does not mean that you can partition all users in batch of "10% of features".
If you want to satisfy everyone, you have to make every possible combination of "10% of word features". Which is impossible.
So it's much easier to just combine all features in one product and try to give the user a good interface to find easily the feature they are looking for.
> If you want to satisfy everyone, you have to make every possible combination of "10% of word features". Which is impossible.
I remember Caddy used to have a "kitchen sink" packager or something like that available via their website, where you could pick and chose what features you'd want included.
Playing with the idea (I'm not saying it's a good idea or that I want it), Microsoft could offer something similar, where you tick boxes for what use-cases you want it to fit, and bundle it all together for you with a price per use-case.
I'd absolutely hate it, as I never know what I need in the future, but maybe for some people it'd make sense.
It's been almost 20 years since I compiled linux, but it was kind of like that. You would choose the features you needed and ignore the rest. Other compiled applications generally have options you can pass to make to enable certain features. Python readline comes to mind.
It would be interesting if we had a similar system for GUI applications. The interface would need to be generated to only show features that are included
Because the cost of production does not scale in a reasonable manner, nor would it be good for users. What happens when you need feature X that is only available in 6th edition, or need to open a document prepared in the 8th edition by someone else?
Things can be feature complete, and they often are at many businesses.
You need to build a solution to problem x. You do that and then the project is over. Outside of maintenance work it's a stable code base and you the developer move onto a new problem.
Examples of this in my mind are things like uBlock Origin. I'm not getting bombarded with updates on that project. It does the job it sets out to do, and it does it well.
This would be what I ideally think should happen, a product hits a happy place and is finished.
It seems, though, that when working in a business that you'll have many users with many use cases, you'll be competing with other software companies, the temptation is there to add the one feature more to please the user or compete a little better.
this becomes a very specific problem each group of developers / business must answer and maybe the ideal case becomes less realistic to achieve or at least have a general answer for.
This is because you hired developers on payroll and it would be a dumb strategic move to fire everyone once the product is "finished." You have to keep building things in order to justify having people on payroll (otherwise you're paying them to do nothing every day).
If you take VC funding you're in for another world of pain, which is that your company may be perfectly profitable but if it isn't growing at a rate your investors want you'll get kicked out and replaced by someone who will take "product growth" seriously. In other words, Postman needs more paying customers so it needs to become more of a "one size fits all" tool.
One might think that the solution is to simply work on another product after Postman was declared "done," but it seems like nobody seriously attempts this anymore because the SaaS model is so much more profitable.
I really like how GitLab allows you to disable the container registry, issue tracker, CI and every other module if you don't use/need it. IMO this should be the way to introduce new features where at all possible.
Same with Github, you can disable issues or projects or whatever other features they have at a repo level.
I agree that this and feature flags are a great way to toggle things, but unfortunately for apps like Postman you still feel the load in the download and load times for the app. Usually those fancier features are also more code/data which results in straight increases in memory/disk regardless of whether you use something or not.
In IDEs like Jetbrains and VisualStudio, a lot of features are built like plugins which are a separate download and installation and allow you to disable them. I wonder if apps could take that approach to to keep more people happy.
You've heard of the Unix philosophy? Small programs that do one thing well. Composeability, so you can combine programs to make new functionality.
Rather than build one console app that has 50 features, you build 10 console apps with 10 features each. The complexity of each component stays small while your capabilities as a user grow and grow.
This worked originally as the Unix designers were free to organize their code however made sense according to their philosophy. But Conway's Law comes into play in organizations, where there is always a hierarchy centred around one or two main products. Rather than one or two people making 10 different apps, it's multiple teams making a couple apps each. They don't communicate between each other well or understand the other components, and it all has to fit inside one program.
> You've heard of the Unix philosophy? Small programs that do one thing well. Composeability, so you can combine programs to make new functionality.
That makes sense in terms of CLI utilities where text/files is the standard input/output, or APIs where json/xml/format-of-today is the standard input/output, but how would you do this with GUI tools? I'd love it if there was a solution, but I'm not aware of one.
Many suites of software use a standard format for things (like .obj/.fbx for graphic object/animation, or .wav for music production), but there is usually not a pipeline as in "pipe this output from this software into that input to that software" like we do with CLI utilities, and if there is, that pipeline is not standarized nor open for extension. Will it ever be possible? I hope so, but I don't see how it can be right now.
An option here might be things like COM and DCOM. Individual, possibly embedded, components and a well defined communications mechanism.
Historically the Amiga was quite nice here with systems using AREXX to communicate (but not embed), and Linux/POSIX has things like DBUS for the same (but less flexibly since there's no middleware between the two for coordinating control between systems, the components need to know about one-another directly - kinda).
As a comparison against traditional unix pipes (or even sockets), how does DBUS handle sending/receiving a lot of data? I always got the impression DBUS is more for notification style message passing, not actually for sending data, so you'd send a message saying "fetch the data from this socket" rather than "here's a bunch of data for you".
I always wonder we have usable version numbers for API's or packages but why not for UIs. It would be nice to have the ability to switch the app to a specific version in the past.
Companies must show revenue improvements or they die. A vanilla REST client is pretty damn hard to monetize. That makes the Postman team's decisions perfectly rational. It's simply the way the world works.
if you want to survive in silicon valley you need to show growth in terms of revenue or at-least the number of users on your platform. Thats a slippery slope for products like postman.
It's also the demogrpahic of the internet. Internet is abundant with, for a lack of a better term, toxic people. Which makes sense if you think about it, since on the internet you can be toxic with very very little to no consequences. Lot of toxicity comes out in the form of criticisms. On a moderated forum like HN it's not easy to criticize a person, so you go for the next good thing - a company or a new area.
If one just reads the HN solely, they might get the impression that Google is the most evil company on the earth since the beginning of time. In reality very few people actually have that kind of view. It's mostly toxic people need to find a target to unleash their toxicity; on HN it's Google.
Since you are young, I'd advise to be very cautious on internet. Never take internet crowd as a proper sample of real world population. It's very skewed and almost always not in a good way.
I agree with you. It seems funny to me in a lot of these threads about new features that people complain about them, then when somebody recommends program "XYZ" they complain "but there hasn't been any updates in 2 years, it's obviously not good or not used and I don't want to get stuck using an obsolete package".
Very solid development but please disable those pop ups that you have to update your postman (always delivers) suite. That is very annoying. I went back to version 7.x because of this.
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.