[HN Gopher] Postman Now Supports gRPC
___________________________________________________________________
Postman Now Supports gRPC
Author : ace33
Score : 368 points
Date : 2022-02-02 12:45 UTC (10 hours ago)
(HTM) web link (blog.postman.com)
(TXT) w3m dump (blog.postman.com)
| dec0dedab0de wrote:
| 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 wrote:
| 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 wrote:
| 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.
| soraminazuki wrote:
| 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
| a85 wrote:
| I'll look into it. Thanks for pointing it out!
| smoyer wrote:
| 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.
| fooaccount123 wrote:
| https://github.com/postmanlabs/postman-app-support/issues/27...
| lol
| paozac wrote:
| 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.
| theFluke wrote:
| 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.
| wackget wrote:
| RESTER on Firefox: https://addons.mozilla.org/en-
| US/firefox/addon/rester/
| adam_arthur wrote:
| 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
| ljm wrote:
| New law: Any novel product with VC funding will inevitably
| grow a vestigial CMS.
| cyral wrote:
| 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.
| BiteCode_dev wrote:
| Incidently, httpie is getting a GUI:
| https://github.com/httpie/desktop
| skrebbel wrote:
| And VC funding!
| capableweb wrote:
| 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...
| jkbr wrote:
| 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.
| stavros wrote:
| > I wonder how long time it'll take for them to end up
| trying to extract as much value from each user as
| possible...
|
| As long as it'll take for the investment documents to be
| signed.
| revscat wrote:
| Source? I really hope this isn't the case. Fucking
| capitalists kill everything.
| skrebbel wrote:
| 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.
| mook wrote:
| https://httpie.io/about says they've had a seed round
| already. Looked it up because that sounds... well it is
| what it is.
| danuker wrote:
| > 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.
| lucideer wrote:
| 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 wrote:
| This sounds unbelievable but it seems to be true?
| https://github.com/postmanlabs/postman-app-
| support/issues/10...
| judge2020 wrote:
| This is OP's issue: https://github.com/postmanlabs/postman-
| app-support/issues/38...
| bathtub365 wrote:
| I don't see anything in this issue that I'd characterize as
|
| > The developers stating they had no intention of changing
| this for "security reasons" before closing the Github issue
| sealed the deal.
|
| The issue is still open with no response from the
| developers that mentions security reasons.
| lucideer wrote:
| 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.
| cloverich wrote:
| Its in issue in the sibling comment. The suggested work-
| around is to not sign in at all.
| lucideer wrote:
| 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.
| a85 wrote:
| That is incorrect. You can save requests inside
| Collections in the Scratchpad and send requests without
| an account.
| lucideer wrote:
| Not sure what I said that's incorrect?
|
| 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.
| sbmthakur wrote:
| > 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.
| dewey wrote:
| 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.
| ROARosen wrote:
| On the on Microsoft Edge chromium you can can enable an
| "edit and resend" feature save the requests to
| "Collections" and create request environments.
| panzerklein wrote:
| It seems pretty easy with Firefox - there's "Edit and
| resend" in the context menu of every request.
| dewey wrote:
| 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.
| ROARosen wrote:
| Se above. On MS Edge chromium you can enable to save the
| requests and even saved environments
| nerdite wrote:
| I take that curl command to https://curlconverter.com
|
| And get Python that I can start iterating on. They have
| lots of languages.
|
| I used to use Postman but the clarity of the code is so
| much easier to see what's happening vs postman imo.
| nileshtrivedi wrote:
| Try Insomnia or Hoppskotch.
| oweiler wrote:
| How is Insomnia any different? It's basically an OSS carbon
| copy of Postman.
| BoorishBears wrote:
| You asked how it's different then stated how it's
| different.
|
| Because it's OSS they didn't feel the need to bog down a
| perfectly functional product to drive a valuation up.
|
| It's a carbon copy of what Postman started as.
| piaste wrote:
| I switched to Insomnia about a year ago for two main
| reasons:
|
| - Didn't choke when having ~50 request 'tabs' open
|
| - Didn't try to sell me shit
|
| Granted, Postman had quite a lot more tools in its box for
| scripting, testing, sharing etc. but I didn't need those.
|
| Insomnia has got a bit fatter since then, but it remains
| more responsive than Postman was.
| phgn wrote:
| That's what I want. A local-only Postman without too many
| features or configuration overhead. Insomnia is almost
| perfect for that.
| hadrien01 wrote:
| 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.
| chin7an wrote:
| 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 wrote:
| No, we are not gonna kill native macOS app![0]
|
| [0] I'm lead developer for macOS app :)
| lukevp wrote:
| 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.
| capableweb wrote:
| > 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.
| david38 wrote:
| 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.
| chin7an wrote:
| Really hoping the native app survives. Thanks for the great
| app! I've been a user for a long time and hope to remain
| so.
| 9dev wrote:
| 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 :)
| tluyben2 wrote:
| 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 wrote:
| 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.
| ironmagma wrote:
| I've found Hurl to be quite usable.
|
| https://hurl.dev/
| mattbuilds wrote:
| 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 wrote:
| 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.
| [deleted]
| zimpenfish wrote:
| > 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.)
| eatonphil wrote:
| 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
| robofanatic wrote:
| 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.
| lovedaddy wrote:
| The latest updates from httpie have an insomnia type rest
| client workspace thing.
|
| https://httpie.io/product
| piokoch wrote:
| This is some invite only software, am I missing something? I
| couldn't use it right away, I was asked to join waitlist.
| jkbr wrote:
| 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.
| magicalhippo wrote:
| 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
| sillyquiet wrote:
| Same story here. Postman just got too feature-rich for my
| blood.
|
| curl + bloomRPC + graphiQL covers all my bases nowadays.
| thomaswormald wrote:
| 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
| nr2x wrote:
| Pretty sure the entire value prop of gRPC is to help Xooglers
| avoid learning modern tools.
| truthwhisperer wrote:
| 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.
| newusertoday wrote:
| 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 wrote:
| Thank you for linking it!
| hbn wrote:
| 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.
| robofanatic wrote:
| they shouldn't have moved the company to silicon valley
| lnenad wrote:
| 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 wrote:
| 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/
| kawemi wrote:
| 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.
| adhoc_slime wrote:
| 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.
| johncena33 wrote:
| 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.
| throwaway984393 wrote:
| 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.
| capableweb wrote:
| > 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.
| throwaway984393 wrote:
| Linux GUI apps use DBUS to communicate between each other.
| (I'm not a fan of it but it's better than nothing)
| capableweb wrote:
| 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".
| pas wrote:
| You can use DBus to call a remote procedure and pass the
| path of a temp file where the real data is.
|
| (You can pass actual file descriptors too.)
|
| That said DBus is pretty fast. Basically somewhere around
| 25-30% of TCP.
|
| https://blogs.gnome.org/abustany/2010/05/20/ipc-
| performance-...
| tluyben2 wrote:
| I definitely rather would have had a second (and third and
| further,...) app. But I guess most people do not.
| robofanatic wrote:
| 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.
| pm90 wrote:
| 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.
| viro wrote:
| man, terraform errors are VERY vague. at least when I was
| using it.
| croes wrote:
| 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
| chrisdhal wrote:
| 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.
| lugu wrote:
| There might be two types of features: those designed for the
| existing user base, and those to extend this user base.
| cannonpalms wrote:
| 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.
| matsemann wrote:
| 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 wrote:
| 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.
| Mindstormy wrote:
| 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.
|
| https://i.redd.it/cfnqsnldc1d81.png
| capableweb wrote:
| > 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.
|
| It's really not that complicated.
| dec0dedab0de wrote:
| 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
| elcomet wrote:
| That does not work.
|
| 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.
| capableweb wrote:
| > 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.
| joatmon-snoo wrote:
| That's called a competing product :)
| jen20 wrote:
| 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?
| dgudkov wrote:
| Postman raised $433M so far. Feature bloat is inevitable.
| franga2000 wrote:
| 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 wrote:
| 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.
| robofanatic wrote:
| 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.
| woofcat wrote:
| 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_slime wrote:
| 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.
| nexuist wrote:
| 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.
| a85 wrote:
| 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 wrote:
| Thoughts on having native clients for Mac/Windows?
| a85 wrote:
| 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.
| guptarohit wrote:
| 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.
| lambda_dn wrote:
| 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.
| nexuist wrote:
| 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_dn wrote:
| Don't ever for an interview at Google they will laugh you out
| the room.
| hngpt2 wrote:
| ynouri wrote:
| 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 wrote:
| 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.
| ynouri wrote:
| 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
| ProtocallDev wrote:
| 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.
| brian_herman wrote:
| I can't wait for native support for SOAP. It would be great to
| have a competitor to SOAPUI.
| serverholic wrote:
| How about better graphql support? Insomnia is kicking postman's
| but in that department and my team had to switch.
| PaulAnunda wrote:
| While the OSX client has become quite bloated, I find
| https://web.postman.co/ to be a good experience.
| shp0ngle wrote:
| 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 :(
| throwingawayyou wrote:
| AtNightWeCode wrote:
| 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 wrote:
| 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
| mythz wrote:
| 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 wrote:
| 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?
| pm90 wrote:
| 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.
| [deleted]
| cyberpunk wrote:
| 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
| locusofself wrote:
| 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.
| jonfk wrote:
| 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 wrote:
| 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...
| sudhirj wrote:
| Thanks, I've had Idea Ultimate All Products for years and
| never heard of this.
| stickfigure wrote:
| 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.
| kgeist wrote:
| 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.
| andyfleming wrote:
| You can use the .http file syntax and use with both VS
| Code[1] and IntelliJ's HTTP client.
|
| [1] https://marketplace.visualstudio.com/items?itemName=hum
| ao.re...
| y4mi wrote:
| 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
| joshstrange wrote:
| 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.
| souldeux wrote:
| This is awesome, I had no idea you could do this. And with
| gRPC built right in!
| rattray wrote:
| 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 wrote:
| 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?
| CSSer wrote:
| 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.
| jonfk wrote:
| 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
| CSSer wrote:
| Thanks for that! Sorry, I was in a bit of a hurry earlier.
| I should've thought to check the commit authors for the
| site.
| panabee wrote:
| what other areas of the request process did you want to hook
| into?
| tpoindex wrote:
| 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.
| teaearlgraycold wrote:
| > 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 wrote:
| With your reasoning, wouldn't it be work as well to dictate a
| certain Linux distro?
| piaste wrote:
| 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.
| sangnoir wrote:
| > 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.
| mastazi wrote:
| > 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...
| e12e wrote:
| > 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/
| redisman wrote:
| 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
| pkulak wrote:
| 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.
| sorahn wrote:
| I've been using BloomRPC for the past year, but it's definitely
| got a few rough spots.
|
| Very excited to try this out.
| thcyron wrote:
| 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.)
| evanmoran wrote:
| Looks great! How's the reception so far? Many of our APIs
| have some streaming, is that something on your roadmap?
| thcyron wrote:
| It's definitely on the roadmap. Out of curiosity, do you
| use client/server streaming or bidirectional streaming?
| evanmoran wrote:
| 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
| ProtocallDev wrote:
| 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.
| dewey wrote:
| Very nice, thanks for sharing. I'll take a look.
| avel wrote:
| 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.
| halpert wrote:
| Doesn't curl do this just as easily?
| IshKebab wrote:
| 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.
| halpert wrote:
| 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.
| avel wrote:
| This extension also keeps a history of requests.
|
| 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.
| halpert wrote:
| You can have curl read the request body from a file using
| --data @filename.txt.
| piaste wrote:
| Which means you've opened an editor already to edit the
| request. Might as well send the request right there via
| an editor command/plugin.
| avel wrote:
| Someone posted https://hurl.dev/ below. It looks like a
| command-line alternative to this, with a similar format, and
| support for assertions.
| jicea wrote:
| 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
| judge2020 wrote:
| 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.
| nexuist wrote:
| 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 wrote:
| Yes it supports variables, don't know about KV store, see: ht
| tps://marketplace.visualstudio.com/items?itemName=humao.re...
| eadmund wrote:
| Those of y'all frustrated with Postman might be interested in
| restclient.el: https://github.com/pashky/restclient.el
| thcyron wrote:
| For people looking for a native macOS client for gRPC, check out
| Grip (https://gripgrpc.dev). (Disclosure: I'm the author.)
| zanedeg wrote:
| Correct URL: https://gripgrpc.dev/
| karolsputo wrote:
| 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...
| Nihilartikel wrote:
| 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.
| kedihacker wrote:
| Is there efficent binary formats like grpc which doesn't require
| a predefined schema?
| davidjfelix wrote:
| 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.
| rmorey wrote:
| Something like this? bsonspec.org
| dewey wrote:
| 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.
| fasteo wrote:
| Strangely enough, I came here to look for Postman alternatives in
| the comments.
|
| Not disappointed !
| CommonGuy wrote:
| 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
| LoveGracePeace wrote:
| 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/
___________________________________________________________________
(page generated 2022-02-02 23:02 UTC)