Postman Now Supports gRPC

https://blog.postman.com/postman-now-supports-grpc/

by ace33 • 4 years ago

409 210 4 years ago

blog.postman.com

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.

sorahn• 4 years ago

I’ve been using BloomRPC for the past year, but it’s definitely got a few rough spots.

Very excited to try this out.

thcyron3• 4 years ago

If you’re on the Mac, you might want to give Grip (https://gripgrpc.dev) a chance. It’s a native client for gRPC. (Disclosure: I’m the author.)

dewey4• 4 years ago

Very nice, thanks for sharing. I'll take a look.

evanmoran2• 4 years ago

Looks great! How’s the reception so far? Many of our APIs have some streaming, is that something on your roadmap?

dewey4• 4 years ago

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.

paozac• 4 years ago

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.

nileshtrivedi• 4 years ago

Try Insomnia or Hoppskotch.

oweiler• 4 years ago

How is Insomnia any different? It's basically an OSS carbon copy of Postman.

tluyben22• 4 years ago

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

quambene• 4 years ago

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.

lovedaddy• 4 years ago

The latest updates from httpie have an insomnia type rest client workspace thing.

https://httpie.io/product

piokoch• 4 years ago

This is some invite only software, am I missing something? I couldn't use it right away, I was asked to join waitlist.

danuker• 4 years ago

when it was a simple browser extension

You can download packages of extensions. I would recommend that you do it for the ones you love.

But the browser APIs are constantly changing, forcing you to keep running in order not to fall behind.

sbmthakur2• 4 years ago

I basically used it as a curl gui.

I just use Browser's Network tab for that nowadays. CORS can be a trouble at times, but that can be avoided with a few tweaks.

dewey4• 4 years ago

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.

eatonphil• 4 years ago

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.

Always happy for any feedback!

https://github.com/multiprocessio/datastation

sillyquiet• 4 years ago

Same story here. Postman just got too feature-rich for my blood.

curl + bloomRPC + graphiQL covers all my bases nowadays.

chin7an2• 4 years ago

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.

[0] https://paw.cloud/ [1] https://rapidapi.com/

jim180• 4 years ago

No, we are not gonna kill native macOS app![0]

[0] I'm lead developer for macOS app :)

mattbuilds• 4 years ago

I used to use Postman but now I prefer to just build my own scripts in Python. I use the requests library and can setup things however I want.

anyfactor• 4 years ago

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.

robofanatic4• 4 years ago

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.

BiteCode_dev• 4 years ago

Incidently, httpie is getting a GUI: https://github.com/httpie/desktop

skrebbel2• 4 years ago

And VC funding!

hadrien01• 4 years ago

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.

theFluke• 4 years ago

If you're on macOS, Auxl (https://auxl.io) is another option to try. Support for gRPC should be coming soon. Disclosure: I am the author.

lucideer5• 4 years ago

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.

kaszanka• 4 years ago

This sounds unbelievable but it seems to be true? https://github.com/postmanlabs/postman-app-support/issues/10...

adam_arthur• 4 years ago

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

cyral• 4 years ago

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.

ljm• 4 years ago

New law: Any novel product with VC funding will inevitably grow a vestigial CMS.

ironmagma• 4 years ago

I’ve found Hurl to be quite usable.

https://hurl.dev/

magicalhippo• 4 years ago

I found SoapUI when I had to develop some SOAP services, but these days it also does REST etc just fine.

For someone like me who just does this occasionally I found it rather useful.

[1] https://www.soapui.org

wackget• 4 years ago

RESTER on Firefox: https://addons.mozilla.org/en-US/firefox/addon/rester/

shp0ngle• 4 years ago

postman is a software that I simultaneously love and hate

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

hbn• 4 years ago

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.

robofanatic4• 4 years ago

they shouldn't have moved the company to silicon valley

kawemi• 4 years ago

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.

lnenad2• 4 years ago

Completely agree, I've started making my own open source lightweight version

https://github.com/lnenad/probster

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.

dwmbt• 4 years ago

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.

[1] https://opencollective.com/

bladelessninja2• 4 years ago

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.

adhoc_slime2• 4 years ago

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.

tluyben22• 4 years ago

I definitely rather would have had a second (and third and further,...) app. But I guess most people do not.

robofanatic4• 4 years ago

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.

chrisdhal• 4 years ago

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".

Can't win I guess.

matsemann• 4 years ago

You can't win. Most features added is because someone wants them. One person's bloat is another person's long sought feature.

Like a quote about Microsoft Office: A user only ever uses about 10 percent of the features. The problem is that all users use different 10 percents.

CSMastermind• 4 years ago

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.

woofcat• 4 years ago

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.

adhoc_slime2• 4 years ago

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.

franga2000• 4 years ago

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.

meesles• 4 years ago

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.

throwaway9843932• 4 years ago

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.

capableweb6• 4 years ago

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.

johncena33• 4 years ago

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.

lugu• 4 years ago

There might be two types of features: those designed for the existing user base, and those to extend this user base.

robofanatic4• 4 years ago

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.

pm902• 4 years ago

This is an excellent question.

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.

viro2• 4 years ago

man, terraform errors are VERY vague. at least when I was using it.

cannonpalms• 4 years ago

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.

croes• 4 years ago

Plugins or extension are the way to go. So if you need a feature you can install it.

VS Code gained its success mainly because of it's extensibility through extension

dgudkov• 4 years ago

Postman raised $433M so far. Feature bloat is inevitable.

mythz• 4 years ago

We've moved on from Postman for our own APIs and are now including an integrated API Explorer into each new .NET v6+ App https://docs.servicestack.net/api-explorer

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

dschuessler• 4 years ago

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?

kedihacker• 4 years ago

Is there efficent binary formats like grpc which doesn't require a predefined schema?

rmorey• 4 years ago

Something like this? bsonspec.org

davidjfelix• 4 years ago

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.

thomaswormald• 4 years ago

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

soraminazuki• 4 years ago

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.

[1] https://web.archive.org/web/20190322170311/https://github.co...

[2] https://github.com/postmanlabs/httpbin

a859• 4 years ago

I'll look into it. Thanks for pointing it out!

serverholic• 4 years ago

How about better graphql support? Insomnia is kicking postman's but in that department and my team had to switch.

a859• 4 years ago

Many many improvements coming soon to GraphQL tooling in Postman.

pm902• 4 years ago

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.

Nihilartikel• 4 years ago

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.

smoyer• 4 years ago

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.

avel3• 4 years ago

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.

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

  POST https://example.com/comments HTTP/1.1
  content-type: application/json

  {
    "name": "sample",
    "time": "Wed, 21 Oct 2015 18:27:50 GMT"
  }

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.

judge20202• 4 years ago

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.

nexuist3• 4 years ago

Yes, it seems like it:

"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.

cloudrkt• 4 years ago

Yes it supports variables, don't know about KV store, see: https://marketplace.visualstudio.com/items?itemName=humao.re...

halpert4• 4 years ago

Doesn’t curl do this just as easily?

IshKebab• 4 years ago

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.

avel3• 4 years ago

Someone posted https://hurl.dev/ below. It looks like a command-line alternative to this, with a similar format, and support for assertions.

jicea• 4 years ago

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

[1] https://hurl.dev

[2] https://hurl.dev/docs/tutorial/ci-cd-integration.html

sharat87• 4 years ago

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.

nichos• 4 years ago

There's also insomnia: http://insomnia.rest/

Which is an open source, cross platform alternative to postman.

Cthulhu_2• 4 years ago

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.

seanw444• 4 years ago

For you Emacsers that haven't heard of it, the alternative to this https://github.com/pashky/restclient.el

Super straightforward.

saikatsg• 4 years ago

Also, Thunder client is a lightweight REST API client extension for VS Code. Good fit for basic usage requirements.

thcyron3• 4 years ago

For people looking for a native macOS client for gRPC, check out Grip (https://gripgrpc.dev). (Disclosure: I’m the author.)

zanedeg• 4 years ago

Correct URL: https://gripgrpc.dev/

karolsputo• 4 years ago

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.

[0] https://github.com/postmanlabs/postman-app-support/issues/81...

jonfk2• 4 years ago

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.

[1] https://httpyac.github.io/

binwiederhier• 4 years ago

TIL about the intellij http client. Thank you for mentioning that. It looks awesome.blike Postman, but built-in to the IDE I have open anyway.

https://www.jetbrains.com/help/idea/http-client-in-product-c...

https://www.jetbrains.com/help/idea/exploring-http-syntax.ht...

joshstrange• 4 years ago

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.

kgeist• 4 years ago

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.

sudhirj• 4 years ago

Thanks, I’ve had Idea Ultimate All Products for years and never heard of this.

stickfigure• 4 years ago

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.

souldeux• 4 years ago

This is awesome, I had no idea you could do this. And with gRPC built right in!

CSSer2• 4 years ago

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.

jonfk2• 4 years ago

Here is the github repo for httpyac [1]. Not sure why it's not part of the httpyac org that hosts the site.

[1] https://github.com/AnWeber/httpyac

tpoindex• 4 years ago

There certainly are plenty of Postman alternatives out there, one that I've used before is Milkman: https://github.com/warmuuh/milkman

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.

e12e• 4 years ago

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

https://httptoolkit.tech/

pkulak• 4 years ago

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.

redisman• 4 years ago

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

mastazi• 4 years ago

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.

[1] e.g.both Postman and Insomnia break when you import multiple API keys https://swagger.io/docs/specification/authentication/api-key...

rattray• 4 years ago

Hoppscotch (https://hoppscotch.io/) is another one I've heard good things about.

Personally I like the VSCode REST Client best: https://marketplace.visualstudio.com/items?itemName=humao.re...

the_arun• 4 years ago

Do they have desktop client? Hoppscotch seems to be web client. How secure is it to use authtokens for our API endpoints from a website?

panabee• 4 years ago

what other areas of the request process did you want to hook into?

teaearlgraycold3• 4 years ago

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.

htgb• 4 years ago

With your reasoning, wouldn't it be work as well to dictate a certain Linux distro?

sangnoir• 4 years ago

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.

piaste3• 4 years ago

I am legitimately unsure whether or not your comment is satire of a certain kind of pointy-haired middle managers. If it is, it's very well done.

eadmund• 4 years ago

Those of y'all frustrated with Postman might be interested in restclient.el: https://github.com/pashky/restclient.el

dec0dedab0de2• 4 years ago

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.

rplnt• 4 years ago

To be fair, you can export python code from Postman as well.

And it allows you to load swagger/openapi spec which makes the exploration phase rather trivial.

disclaimer: I also hate using Postman because it's too big, complex, slow

toqy• 4 years ago

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.

PaulAnunda• 4 years ago

While the OSX client has become quite bloated, I find https://web.postman.co/ to be a good experience.

lambda_dn2• 4 years ago

Bloatware that is a heave ugly GUI wrapper over cli tools like curl. Learn bash scripting and you will have unlimited power and speed vs this crap.

nexuist3• 4 years ago

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.

lambda_dn2• 4 years ago

Don't ever for an interview at Google they will laugh you out the room.

guptarohit• 4 years ago

Postman used to be a go-to tool for testing APIs, now I use anything else (curl, httpie, etc) but postman. Too much is some time too less.

hngpt2• 4 years ago

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.

fooaccount123• 4 years ago

https://github.com/postmanlabs/postman-app-support/issues/27... lol

newusertoday• 4 years ago

if you are using emacs you can also give this a shot https://github.com/federicotdn/verb

It lets you write the api, test it and generate the documentation all from the same source of truth file.

federicotdn• 4 years ago

Thank you for linking it!

cyberpunk• 4 years ago

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..

0: https://portswigger.net/burp

fasteo• 4 years ago

Strangely enough, I came here to look for Postman alternatives in the comments.

Not disappointed !

LoveGracePeace• 4 years ago

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/

locusofself• 4 years ago

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.

CommonGuy• 4 years ago

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!

https://kreya.app

brian_herman• 4 years ago

I can't wait for native support for SOAP. It would be great to have a competitor to SOAPUI.

a859• 4 years ago

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.

atarian• 4 years ago

Thoughts on having native clients for Mac/Windows?

a859• 4 years ago

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.

gravypod2• 4 years ago

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.

a859• 4 years ago

Not sure about the .bin format yet but will check with my team. The immediate next step is multi file support.

ProtocallDev2• 4 years ago

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.

AtNightWeCode2• 4 years ago

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.

mhoad• 4 years ago

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

AtNightWeCode2• 4 years ago

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.

ynouri2• 4 years ago

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.

Btw - we use both Postman & cURL

lysium• 4 years ago

How do you do version control with your postman scripts? That was the biggest issue on my last project.

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.

ynouri2• 4 years ago

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

a859• 4 years ago

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...

nr2x• 4 years ago

Pretty sure the entire value prop of gRPC is to help Xooglers avoid learning modern tools.

liyasthomas• 4 years ago

We're building an open source Postman alternative: Hoppscotch

Web app: https://hoppscotch.io

GitHub: https://GitHub.com/hoppscotch/hoppscotch

Cthulhu_2• 4 years ago

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.

Postman Now Supports gRPC

Related Stories