[HN Gopher] Hoppscotch: Open-source alternative to Postman
___________________________________________________________________
Hoppscotch: Open-source alternative to Postman
Author : MarcellusDrum
Score : 592 points
Date : 2022-02-28 09:38 UTC (13 hours ago)
(HTM) web link (hoppscotch.io)
(TXT) w3m dump (hoppscotch.io)
| callmekatootie wrote:
| My main grouse with these REST GUI clients is how much memory
| they consume. Maybe because they are electron apps in the end,
| but it's just funny that nobody's devoting any time to create
| native apps anymore for something that should be a utility and
| not the main app.
| slim wrote:
| it should be a browser developer tools addon
| TameAntelope wrote:
| Why would I use a browser developer tool to test an API? A
| browser is wholly uninvolved in API development.
| getcrunk wrote:
| That's only true if you aren't testing in prod
| tomc1985 wrote:
| It still makes calls, and a proper REST client means you
| can make POST/PUT/etc on command
| nwsm wrote:
| Most devs who use something like Postman in their normal
| workflow would prefer a standalone client (or cli).
| notpushkin wrote:
| I'm working on something a bit orthogonal, but similar in
| spirit: a "network requests" tool, similar to the Network
| tab in Devtools, but batteries included and working _both_
| as a browser extension and a reverse proxy standalone app -
| so you just pick whatever suites your workflow better
| today. It's still super early stage though.
| _fat_santa wrote:
| Not sure about Windows but for MacOS, Paw is an excellent
| Native app. Thought not worth the $50 for me since I hardly
| ever work on API's.
| ideologysec wrote:
| dunno your operating system, but Paw for macOS is a great
| native REST/API GUI client.
|
| https://paw.cloud/
| eyelidlessness wrote:
| I haven't used Paw because I have very little need for a tool
| in this category lately, but I'm tempted to buy it anyway
| just to reward them for developing a good native Mac UI, and
| not restricting it to a subscription model.
| rubyist5eva wrote:
| ironically, they have a not-mac version that is electron
| based
| liyasthomas wrote:
| Hi HN community, Hoppscotch author here. Ask Me Anything - Liyas
| (https://twitter.com/liyasthomas)
| electroly wrote:
| Will you add an Electron version? A browser-based HTTP client
| is nearly useless for me because of CORS. I couldn't come up
| with any interesting internal endpoints to even test this with.
| I thought "Install app" was going to give me an Electron
| version, but it isn't; it's still the same thing with the same
| restrictions.
| theturtletalks wrote:
| Had a similar issue. You have to use their browser extension:
| https://chrome.google.com/webstore/detail/hoppscotch-
| browser.... Click on this extension and add the domain you
| want to query. Then on Hoppscotch, go to settings and click
| "use browser extension to send requests."
|
| I was using Altair's desktop app to handle CORS, but may
| switch to this set-up.
| MarcellusDrum wrote:
| Hey! So I tried to import a Postman collection, but the pre-
| request scripts aren't getting imported. Neither are the sample
| code snippets. Is this not implemented yet, or is it a problem
| with the collection (or something I'm doing).
| bmn__ wrote:
| Not a question, but a complaint. Your machine translated
| interface falls short of being acceptable. Either give the l10n
| job to a human, or don't do it at all.
| dan1234 wrote:
| With this being open source, perhaps it'd be better to submit
| a pull request rather than a complaint?
| jka wrote:
| Can you provide one or more example(s) of translations that
| aren't great?
| radiantmilk wrote:
| The Swedish translation. I had to switch to English to
| figure out what some buttons did. For example one of the
| buttons at the button show "Jaktplan" (fighter plane).
|
| Also there are a lot of extra spaces inserted in words with
| dashes or colons in them and some strings are simply not
| translated at all.
| bmn__ wrote:
| https://files.catbox.moe/x99gla.webp
|
| Your turn: what was the point of asking?
| tecleandor wrote:
| Probably just to know what were you talking about if we
| aren't fluent in any language that looks _weird_ and we
| couldn't notice it.
| jka wrote:
| Danke. Fixing typos and other small grammatical problems
| in open source projects can be a good, easy way for
| people to get started; so my hope is that by sharing a
| few of those, you've created the opportunity for someone
| (maybe me, maybe another observer here) to contribute an
| improvement to the project. It's also an attempt to
| maximize the value of your complaint.
| rwoerz wrote:
| i10n is internationalization in which language?
| bmn__ wrote:
| fuzzer37 wrote:
| Maybe calm down a bit, nothing constructive comes of
| talking down to people. Especially an open source
| project.
| bmn__ wrote:
| I am calm. I am not talking down. Examine why you made
| bad assumptions, and could not see my post for what it
| is: sharing a hack to improve one's life.
| fredoliveira wrote:
| I'm not GP, but your replies in this thread read as
| arrogant. If you're getting called out by multiple
| people, it is probably not them -- and sure, you may have
| good intentions, but they are not coming across as you
| think.
| fuzzer37 wrote:
| How many downvotes are you up to now?
| cdolan wrote:
| If you create a feature to host a Docs page in the future,
| please improve on Postman's.
|
| Theirs lacks key features and introduces bad ones:
|
| 1. Locks you into their Collections datamodel. Results in the
| API being maintained outside OpenAPI generated files because
| your annotations can't be easily merged with new endpoints. 2.
| Unable to password protect the API docs, even with a basic
| password. 3. Unless this changed recently, there is no way to
| re-order the endpoints or the responses without manually
| removing and re-adding them! Absurd.
| gkoberger wrote:
| You should try ReadMe :) we do all of that, plus let your
| APIs play with the API right in the docs. And a billion other
| cool little features!
| swyx wrote:
| i'm really really curious - how did Hoppscotch get so many
| github stars? sorry if this is superficial but you've reached a
| level of stardom very few projects reach and in seemingly very
| short time.
| birger wrote:
| If I create a team and share requests, do I also share
| passwords and other credentials? If so, where are they stored
| and how secure is that?
|
| I work for a company with many different project. Is there a
| workflow where I can save a workspace as one file and save/load
| it with my project from Git (or any local folder on my
| computer)?
| ndom91 wrote:
| Love hoppscotch! Moved to it from postman back in the postwoman
| days. They really cleaned up the UI recently, made saving and
| sharing collections super easy.
|
| And there's a chrome extension so you can proxy requests through
| your localhost to avoid CORS issues, etc.
| sakethr98 wrote:
| I was going to ask if you had tried postwoman.io, turns out, they
| rebranded to hoppscotch
| lloei wrote:
| Am I going crazy or is there no way to install this locally apart
| from a "development" setup with git clone or docker?
| np_tedious wrote:
| I think you're correct. It's a webserver and they don't seem to
| release binaries
| jraph wrote:
| That's one of the things the .io domain hints at, along with
| the completely blank page when loading the website without JS
| enabled, the myriad of NPM dependencies and the fact that it is
| advertised as a lightweight tool while being a Vue SPA that
| loads 13 M of minified JS code (that's if you block google
| trackers), and google trackers.
| Kovah wrote:
| Interesting that they replaced the product name "Hoppscotch" with
| "Hupfburg" in German. Not sure what's the reason, as it's not
| even a correct translation. German also seems to be the only
| language the devs did that.
| bdcravens wrote:
| I've used both Postman and Insomnia, but recently I've been using
| the REST Client plugin (https://marketplace.visualstudio.com/item
| s?itemName=humao.re...). It's not a feature-rich, but I honestly
| like the workflow of not having to switch apps and work with
| files in my editor (as well as put variables in a .env)
| darekkay wrote:
| There's also an equivalent in IntelliJ IDEA Ultimate:
| https://www.jetbrains.com/help/idea/http-client-in-product-c...
| andiareso wrote:
| Dude yes! Haha I use this all the time! It's so nice to have
| the files in Git too and it's such an easy dev install.
| notpushkin wrote:
| There's also https://httpyac.github.io/ which has both
| standalone CLI and VS Code extension versions - might be
| interesting to explore.
| fredley wrote:
| I got off Postman years ago and have been using Insomnia since
| then: https://github.com/Kong/insomnia
| c0wb0yc0d3r wrote:
| Insomnia has not been a drop in replacement for me, but its
| "request chains" are fantastic. At this point it helps put up
| with its different set of problems.
| udfalkso wrote:
| I hadn't known about request chains, very interesting! Thanks
| ArcMex wrote:
| Will give this a shot and test with https://gorest.co.in/
| silon42 wrote:
| I've also been using it (an older version Insomnia REST), but
| recently I tried to upgrade to a newer version and it's
| unusably slow and has graphics bugs for some reason.
| noisy_boy wrote:
| Very similar experience for me too - once Postman starting
| nagging about enterprise-y stuff/account creation etc, I
| switched to Insomnia and I really enjoy using it. Beyond the
| typical REST/graphQL support, it has the ease-of-use features
| like environments/grouping via directory structure/variables
| etc while not requiring any sign-up, allowing local
| export/import without having to go through cloud etc.
|
| The only concern I had was lack of support for multiple tabs
| (which Postman allows) but having used it for a while, I don't
| find this to be an issue anymore; infact, I like that I no
| longer have to tab hunt like I used to in Postman with scores
| of open tabs building up over time.
| electroly wrote:
| IMO, Insomnia has been bloating up to the point of ruin just
| like Postman did. I've moved from Postman -> Insomnia -> HTTPie
| beta GUI. The number of clicks between a new Insomnia
| installation and typing in the URL for your first request is
| absurd.
| _fat_santa wrote:
| I just tried HTTPie beta GUI. For an app that is basically a
| wrapper of their CLI, not sure why I would need an account
| and join a waitlist. No thanks.
| mdtrooper wrote:
| Is there a HTTPie GUI?
|
| is https://github.com/httpie/desktop ? I don't know this
| project.
|
| Thanks.
| HNHatesUsers wrote:
| Just tried Insomnia, and it doesn't support OpenAPI 3.1.
|
| Too bad.
| nerdponx wrote:
| I raised an issue for this a while ago. Insomnia uses the
| Swagger UI library, which _also_ (bizarrely) doesn 't support
| 3.1, so Insomnia is blocked until that library is updated.
| idoubtit wrote:
| I wanted to try Insomnia, but could not install their deb
| package on my Debian: it depended on a "libappindicator3-1"
| which is not available in my current release. I'll stick to
| basic CLI tools when I experiment with web APIs.
|
| The Swagger editor doesn't support OpenAPI 3.1 either, which
| is surprising since the OpenAPI spec was initially ported
| from the Swagger format.
| mschuster91 wrote:
| > it depended on a "libappindicator3-1" which is not
| available in my current release.
|
| That "libappindicator" library being dropped isn't the
| first time there were problems. The article in yesterday's
| Steam/Proton post also mentioned it
| (https://news.ycombinator.com/item?id=30490570). And in any
| case it seems like it's either considered feature-complete
| or abandoned, there have been no code-related commits for
| 12 years now (per https://bazaar.launchpad.net/~indicator-
| applet-developers/li...).
| ganomi wrote:
| I have been using Insomnia for a few years now but was blown
| away when a colleague told me i could right click the send
| button and get some additional features... Crazy UI anti
| pattern. There is no hint that this button has a secondary
| functionality.
| eyelidlessness wrote:
| It's impressive that there's a clear effort to make the UI usable
| on mobile. A very rare thing for developer tools which aren't
| specifically mobile oriented.
| Jiejeing wrote:
| Nowadays I am quite satisfied with the RESTer firefox addon:
| https://github.com/frigus02/RESTer. This does look neat but there
| is no explanation on how to install it locally, and telemetry is
| enabled by default.
| [deleted]
| Justsignedup wrote:
| Not to be confused with hopscotch the kids' programming game
| which is an awesome app for teaching kids coding concepts
| https://www.gethopscotch.com/
| 0xhh wrote:
| I use httpie
| bmn__ wrote:
| Better: https://curlie.io/#differences-with-httpie
| https://github.com/ducaale/xh#how-xh-compares-to-httpie
| kbd wrote:
| Agree, after researching this a little while ago, those are
| the two best alternatives. Was bit by HTTPie not supporting
| HTTP2, but both of those do. xh (Rust) is also faster (yes,
| in practice, try some large responses) than HTTPie (Python).
|
| Edit: also just want to say, in a world where "the current
| GUI tool du-jour got bloated and this one has hidden behavior
| when you right click this button...", I much prefer command
| line tools where possible!
| Justsignedup wrote:
| I've been using https://insomnia.rest/ and I am a massive fan.
| From the ability to make dependent API calls to say log in with
| one API call, and inject login tokens into the other from the
| first's response is amazing!
|
| Overall this tool has been my go-to for 3 years now.
| bstar77 wrote:
| I've personally moved to Talend. Talend is browser based and
| capable of using existing auth cookies. It's a game changer if
| you have to work in an integrated environment where it's not
| possible to run those auth services locally.
|
| When I started using Talend this was not possible in Postman or
| others. Curious if that's changed.
| mohanmcgeek wrote:
| https://www.thunderclient.com/
|
| This one's great. Like postman, but a vscode extension.
|
| Although my muscle memory still automatically goes to postman
| when I want to make requests
| zamalek wrote:
| "rest client" is even better, if you don't mind plain old text
| files (and no gui).
| bdcravens wrote:
| As I commented upstream, I've recently switched to this and
| really like the workflow - sometimes less is more.
| 369548684892826 wrote:
| Perfect, it's exactly what I've been looking for! A lightweight
| and intuitive UI compared to Postman.
| szszrk wrote:
| Wow, I love it. Postman and Insomnia disappointed me, it became
| a mess and push towards sync makes it a bit dangerous to use.
| Thunderclient seems like something to really fill my that void.
| ashleymaverick wrote:
| Yeah this one is just great!
| mittermayr wrote:
| I'll give it a go, looks promising! I have had a great time with
| Insomnia (insomnia.rest) and pretty much anyone I recommended it
| to ended up sticking with it. Postman has became way too bloated,
| it's amazing to see how there's always room for new and slimmer
| approaches.
| bil7 wrote:
| +1 for Insomnia. Incredibly intuitive to use.
| phantomathkg wrote:
| I only wish they can provide a self-hosting step.
| caymanjim wrote:
| Eh? It's totally self-hostable. I run it via Docker on my VPS.
| tragictrash wrote:
| One time I downloaded hopscotch, and it was sending network
| requests to download an asset (css file) on every keystroke. I'll
| never use it again. Ever.
| keithnz wrote:
| I really like https://nightingale.rest/
| HellsMaddy wrote:
| To save you a click: Windows only and closed source.
| freeCandy wrote:
| Interesting to see that the website clearly makes it look
| like the app is open source, the very first thing on the page
| says "View on GitHub". But only upon visiting do you realize
| that the repository is just for bug tracking purposes.
| seanw444 wrote:
| Well that's a first for me. Why not use a standalone bug-
| tracking website or something instead? That's not what
| GitHub's for.
| caymanjim wrote:
| Everyone already has a GitHub account, most people are
| familiar with the UI, it's free, and it works well. Why
| not use it?
| itrollpussies wrote:
| Looks okay but they should have added like a pricing page since
| it's not free.
| ajitid wrote:
| I can't find the pricing page, could you link it? I thought
| it was free.
| itrollpussies wrote:
| I can't find it either, which is why I said they should
| have linked it. In Microsoft Store, you'll see Free+,
| meaning the base version of this app is free, but there are
| in-app purchases.
| einpoklum wrote:
| For those who have no idea what Postman and Hoppscotch are even
| after clicking the link:
|
| > "Hoppscotch is a ... web based API development suite. It was
| builtb ... with ease of use and accessibility in mind ... free-
| to-use ... Open Source
| ttyyzz wrote:
| It's funny how the UI gets unnecessarily translated into German
| for me :)
| numlock86 wrote:
| I noticed that, too. Especially since the tool even presents
| itself as Hupfburg instead of Hoppscotch. But it's nice you are
| able to change the language in the settings of the tool itself
| instead of having to tinker with your browser's language or
| even user agent/request headers.
| lowonkarma wrote:
| very nice, needs some contrast
| SideburnsOfDoom wrote:
| Postman has become a bloated, enterprisey mess.
|
| I want something much simpler, so I use VS code with a "REST
| Client" plugin:
| https://marketplace.visualstudio.com/items?itemName=humao.re...
|
| Fundamentally, IMHO, a very complex and full-featured manual
| testing tool is a liability, as it will lead you away from test
| automation.
| gempir wrote:
| I tried very hard to convince the hoppscotch devs to adapt
| something like .http files so they could be stored in version
| control. Only a few tools get that right.
|
| https://github.com/hoppscotch/hoppscotch/issues/870#issuecom...
|
| Sadly I don't think they never understood the actual goal of
| it. And just added github to sync to or something like that.
| Which isn't what I was looking for.
|
| I use IntellIJ and the http client does it and it works very
| well. But sadly the rest of the http client is annoying just
| basic stuff like reading the response is always a few more
| clicks than I want and compared to Insomnia so much harder.
| kodah wrote:
| Why not spend your time making E2E tests faster and write a
| thin http client for testing that you can run as part of your
| testing framework?
| pmontra wrote:
| I'm not the parent poster. Your question assumes that
| Postman / curl / anything are used to test something. I
| generally use those kind of tools to explore an API and I
| write tests later if I use it or never if the team decides
| to use something else. After all a project defines very few
| APIs but consumes a lot of them from external entities, at
| least in the projects I'm working on.
| netcraft wrote:
| I agree with you about IntelliJ, its great, but rough edges.
| Wish I could cmd+enter to run things too.
| Cthulhu_ wrote:
| > I use VS code with a "REST Client" plugin
|
| This is the way; if anything, your requests are in plain text
| in your version control right next to your code, instead of in
| a proprietary format or intentionally hidden away in a cloud
| service (postman).
| SideburnsOfDoom wrote:
| Yes, "example requests are in plain text, a readable format,
| and easily put in git" is a good goal.
| zamalek wrote:
| Postman collections are just JSON, but that JSON is
| impenetrable to humans and merging algorithms. Rest client
| shows how a good file format can be a huge advantage.
| ArcMex wrote:
| I have got some good usage out of Thunder Client.
|
| https://marketplace.visualstudio.com/items?itemName=rangav.v...
| robertlagrant wrote:
| > Fundamentally, IMHO, a very complex and full-featured manual
| testing tool is a liability, as it will lead you away from test
| automation.
|
| You can build tests in it that can be run in automation via
| Newman.
| SideburnsOfDoom wrote:
| Would you not be better off making those tests in your
| programming language of choice, which is likely the same as
| the code under test, be it Python, Node.js with Mocha, Ruby,
| Java or C# ?
| lambic wrote:
| Or even avoid programming languages as much as possible.
| Most of my API tests are done with curl and jq. (Which I
| blogged about here: https://lambic.ca/blog/api-testing-
| with-curl/)
| lf-non wrote:
| Yeah, I have been using httpie (which offers a better DX)
| in similar fashion.
|
| It also pairs well with (n)vim - I can just run :.!http
| whatever and have the response injected into a vim buffer
| where I can inspect or slice and dice the json with my
| usual vim workflow.
| SideburnsOfDoom wrote:
| I think you're actually testing with bash (and included
| tools) there.
|
| Which is fine, bash is a programming language of sorts (I
| see "if" statements!), and you can store the tests in
| text files in git. If those are the tools that you like
| to use, and it works, great.
| lambic wrote:
| That's why I said "as much as possible". I keep the bash
| scripts as linear as possible so they are "scripts"
| rather than "programs".
|
| We started out using cypress, which I was convinced was
| the wrong tool for testing APIs so I switched to this
| approach, which sped up our CI deployments significantly.
| robertlagrant wrote:
| For testing an API layer, whose different API microservice
| implementations might be in different languages, and/or in
| languages your API test automation team don't understand,
| then that probably wouldn't work well. Why do you think it
| would?
| SideburnsOfDoom wrote:
| I meant to say, what is the case for Newman over "pick a
| programming language that you like and know, and write
| the http tests in that" ?
|
| It was my assumption that the people writing the APIs
| were also writing the tests, so they would prefer the
| familiar language.
|
| If you have "different languages" in play, you get to
| choose one of them for tests. I've seen it happen that a
| language is chosen for test that is not in use in the
| API's at all. It's only "likely" the same language, as I
| said above.
|
| If you have a isolated "API test automation team" then it
| sucks to be you, but the language choice would be on
| them, wouldn't it? I don't think that I implied
| otherwise.
| robertlagrant wrote:
| > If you have a isolated "API test automation team" then
| it sucks to be you, but the language choice would be on
| them, wouldn't it? I don't think that I implied
| otherwise.
|
| You said the tests should be in the implementing
| languages
|
| On the "sucks to be you" - I have test automation folk in
| the team delivering software alongside everyone else as a
| cross-functional team; I just used the word "team"
| loosely to mean "the group of people whose job it is to
| do certain levels of test automation".
|
| > It was my assumption that the people writing the APIs
| were also writing the tests, so they would prefer the
| familiar language.
|
| The point I'm making is makes sense for unit tests, semi-
| unit tests, and possibly also for lower-level API tests
| (e.g. API testing an individual service), but when you
| have to test functionality across services, you might
| well not want to pick a technology that the service(s)
| under test were built in.
| SideburnsOfDoom wrote:
| > You said the tests should be in the implementing
| languages
|
| No, I did not say "should", I said that they would
| "likely" be in the same language, for reasons given
| above. Yes, I get that there are also reasons to
| deliberately choose otherwise.
|
| > but when you have to test functionality across
| services, you might well not want to pick a technology
| that the service(s) under test were built in.
|
| Great. For the third time, what is the case for Newman
| being that technology, over a well-known programming
| language?
| toqy wrote:
| For me it's because people already know and are already
| using Postman. We already author collections for services
| that other devs in the company reference when using our
| APIs.
|
| Sure we could write the tests in python or whatever, but
| everyone is already using and likes Postman for the most
| part. And replacing the postman collections that people
| use for reference with a folder of scripts I don't see
| going over well.
|
| I'd personally prefer something like https://hurl.dev
| where you have a readable file in source control, but
| that's not a battle I'd win at this point.
| robertlagrant wrote:
| > No, I did not say "should", I said that they would
| "likely" be in the same language, for reasons given
| above.
|
| No, you were saying they'd be better off doing it. I was
| saying why that might not be the case.
| SideburnsOfDoom wrote:
| > I was saying why that might not be the case.
|
| I'm still not sure of this case. perhaps you could
| explain it in a bit more detail?
| [deleted]
| hanselot wrote:
| innomatics wrote:
| As a small dev team we have a workflow to rapidly author tests
| integrating our internal and external graphql + rest APIs.
|
| These tests can be run, tweaked and parameterized in various
| environments from the GUI, and then imported into our CI system
| with Newman. Its a low code approach that's saving us time so
| I'm grateful of the features we are getting (for free) with
| Postman.
| mkdirp wrote:
| The syntax of this plugin seems very similar to dot-http[0] and
| IntelliJ's REST client. Super interesting. Would be really
| interesting to have these three fully compatible with each
| other.
|
| [0] https://github.com/bayne/dot-http
| skinnyarms wrote:
| I use both and if there's a difference, I haven't found it
| yet.
| BenoitEssiambre wrote:
| Yeah it's turning it into a tool not for developers, or for
| very poor developers afraid of code.
|
| There might be a market though for people "building APIs"
| through no code/low code tools like zapier and ifttt. Then I
| suppose they can sorta test their low code contraptions with
| this without knowing much about coding.
| SideburnsOfDoom wrote:
| > very poor developers afraid of code.
|
| IDK if I am a "poor dev" but I find the Postman interface
| extremely complex and confusing. There are tabs, dropdowns,
| logins, collections, modes etc. Getting it to work is a
| chore.
|
| A http request written entirely in a text file is IHMO far
| clearer.
| geospeck wrote:
| > I want something much simpler, so I use VS code with a "REST
| Client" plugin
|
| I follow the same approach. Emacs, Verb[0] and org-mode. An
| alternative to Verb would be restclient.el[1] but I like Verb
| more because it works as an extension to org-mode which is
| great for documentation.
|
| [0] https://github.com/federicotdn/verb [1]
| https://github.com/pashky/restclient.el
| scroot wrote:
| I have been using restclient-mode for years and really like
| it, but had never heard of verb -- thanks for the link!
| justinhj wrote:
| verb looks like a game changer for this neanderthal that
| lives in org mode but copy/pastes curl instructions to the
| terminal.
| federicotdn wrote:
| Hope it's useful! You can still export your requests to
| curl, when you want.
| alephnan wrote:
| I was just about to share [Postwoman](https://postwoman.io) but
| it shows this:
|
| Update: 16th August 2020 Postwoman is now Hoppscotch
| luckyshot wrote:
| Is there a way to import data from Postman?
|
| Looks great BTW.
| MarcellusDrum wrote:
| Yes, you can import a collection from Postman. As far as I can
| tell, it doesn't import the Pre-request scripts though, not
| sure why.
| mkdirp wrote:
| Previously called Postwoman, renamed[0] for the following
| reasons:
|
| > 1. Similarity in name with "Postman" may introduce trademark
| violations in future.
|
| > 2. We don't want to hurt any other project's goodwill.
|
| > 3. Rather than being an "alternative to Postman", we focus to
| become the best available testing suite in web.
|
| [0] https://dev.to/liyasthomas/postwoman-is-changing-name-igp
| jspash wrote:
| They are concerned that the name could introduce trademark
| violations. But they continue to ape the UI pixel for pixel?
|
| HN gets upset when the Winkelvoss brothers do this sort of
| thing with website, but it's ok when it's OSS?
| naikrovek wrote:
| uh, hoppscotch and postman look nothing alike on my
| computer...
| ur-whale wrote:
| If, like me, you have strictly no clue what this is for and still
| don't after navigating both the site and the github for 10mn
| (Hoppscotch is a community-driven open source API development
| ecosystem ... ??????), here's an insomnia vid that _sort of_
| starts to clear the fog:
|
| https://www.youtube.com/watch?v=H_k8Z8Zq99s
|
| Here's another for Hoppscotch:
|
| https://www.youtube.com/watch?v=NUz8qpP0Jv8
| MarcellusDrum wrote:
| I thought the title is fine as is, because this project is only
| interesting for those who know what Postman is, which is kind
| of the industry standard in its field. Long story short, both
| of these are tools used for testing APIs. You use them to test
| an API call using different settings, and monitoring the
| response. They have more advanced features of course, but this
| is the main use case.
| suriyaG wrote:
| Is this the project that was previously postwoman? Which was
| discussed here https://news.ycombinator.com/item?id=21607712
| traspler wrote:
| Yes
| torginus wrote:
| Maybe I never appreciated the power of Postman but I never
| understood why they thought it would be a good idea to charge
| _monthly_ for a tool that 's just a gui on top of _curl_ (or
| _Invoke-WebRequest_ for those of a Windows persuasion).
| obowersa wrote:
| To preface this, I'm not a massive fan of postman. I find the
| user experience to be counter intuitive compared to the likes
| of insomnia. With that said we use it pretty heavily so I might
| be able to provide some insights.
|
| This is kind of expanding on koeffiezets comment.
|
| For me postman's 'value add' can be broken down into three
| areas.
|
| Technical Capability:
|
| - UI alternative to curl
|
| This is the most basic usage and a lot of the of other
| functionality is extensions of this. For simple get/post
| requests, this is definitely the case. I wouldn't trivialise it
| though. For folk not familiar with curl there's a lot of
| gotchas when it comes to escaping, handling auth, etc. I'd say
| that the UI on top of curl is more accurately viewed as an
| alternative to things like jetbrains's build in http client.
|
| - The ability to import openapi/swagger/protobuf (as of
| recently) and generate collections
|
| This will be the most commonly pointed at benefit of postman
| (and others like it) in my opinion. It's a pretty solid one,
| especially if you integrate with the API during your build
| process to version/upload the API specs.
|
| This combined the the 'UI alternative to curl' really gives a
| lot of the foundational power for the other postman features.
| Even as openapi/swagger docs on steroids with a richer http
| client this gets pretty powerful. Especially with the sharing
| capabilities which I'll touch on under the team side of things.
| As with a lot of this stuff, you /can/ do this without postman.
| You could use the openapi client generator to produce a curl
| command.
|
| - Auth handling
|
| So postman has pretty rich support for a few auth types (api
| key, no auth, oauth 1.0 & 2.0, signatures, ntlm etc). This I
| think is where some of the power of postman really begins to
| shine (and tools like it). Handling auth in curl can be a real
| pain. Creating a way of handling auth which can be shared
| across a team becomes even more of a pain, especially if we're
| talking about auto refresh and the like. At this point you're
| really in the realm of writing small-medium custom scripts to
| wrap the auth handling, save the tokens, refresh.
|
| Having a standardized way of handling this with the ability to
| extend it if needed can become a massive time-saver.
|
| - Mock Servers
|
| There's a bunch of ways to do mock servers and I wouldn't say
| postman is technically the best ( personal preference is stuff
| like wiremock). With that said, sometimes 'technically the
| best' looses out to what's immediately available. Having it
| built into the system which already has your open api specs,
| has SWE familiarity and is already there will often make this
| win out. It can also get folk thinking a bit more about their
| mocks/contracts than they would be otherwise because it's just
| part of the existing toolchain.
|
| You could technically do this with netcat, or using a language
| specific approach, or another tool like wiremock. The first is
| going to be a pain to maintain, the second doesn't work great
| for multi-language environments and while wiremock and it's ilk
| are easy to get up and running with, they do require additional
| setup and management.
|
| - Postman echo
|
| Kind of an alternative to the like of pipewire or running your
| own nc/other implementation. Simple concept, simple
| implementation, but having the ability to create an endpoint to
| post/etc data to, see what the output looks like and run it in
| a place which other engineers can access and you can
| collaborate easily on the output is a nice to have. Basically
| saving on the setup time/individual contributor trying to
| collaborate side of things.
|
| - Newman
|
| This loops back to curl. A CLI tool for running postman
| collections. I'm giving it a special callout because if it
| wasn't for newman I'd have a lot more reservations about using
| postman. With newman, being able to take collections/imports
| from the UI and then use them with newman to do things like
| helm chart tests/continuous testing/run easily in a container
| allows the effort invested into creating stuff in postman and
| extend it beyond just the local dev experience.
|
| - Other
|
| There's also a whole bit around the API workflow/editor that
| I'm not going to touch on as I dont know that side of it well
| enough, but, it is there and something to be aware off.
|
| 'Team' Capability: With everything above, it's important to
| remember all of this can be done in a shared collaborative
| environment with a full audit trail and potentially SSO
| depending on the tier. Removing all the friction from that is a
| pretty big deal (especially as companies grow).
|
| The point about using a text based standard is valid (one of
| the things I like with jetbrains http client is this). But
| managing that for all the functionality of postman would be a
| challenge and bits would be likely to rot.
|
| Just having a tool which does most of it well enough can be
| enough as it reduces friction.
|
| Another point on this is cross os teams. We have a mix of
| linux/windows/osx users. Curl is great, and does work
| reasonably well on windows, but trying to maintain
| scripts/bespoke implementations/knowledge across folk on all
| these platform is a losing battle.
|
| Integrations:
|
| Kind of a final and often overlooked note, but there's also a
| rich integration system with postman. Stuff like integration
| with new relic/data dog/etc to record test results gives one
| example but it's a pretty solid ecosystem.
|
| Closing thoughts ?
|
| That was a ramble. To summarise: - Postman is definitely
| bloated, but that bloat/bredth of functionality can be useful -
| You can do everything postman does without postman, but
| depending on the team size/number of services/etc there's value
| in having a standardized, cross-os and easy to share solution.
|
| If I was just doing stuff as an individual contributor or had a
| single team ? I wouldn't necessarily go with it. For larger
| orgs or as you go from startup-scale up there are definitely
| advantages in having a master of none tool to help adoption.
| Regardless of if it's postman, insomnia or hopscotch I think
| reducing it to curl with a UI is leaving a lot on the table.
| tgv wrote:
| Makes two of us. Maybe, if you're working on a really large
| project? But then there should be time and money to set up a
| central tool for mockup and testing.
| criddell wrote:
| It's a good idea because there are a lot of companies out there
| who want to pay a monthly fee.
| koffiezet wrote:
| Sorry, but with that attitude, why use curl, and not just
| netcat or socat? Or just write bash scripts manipulating
| sockets directly?
|
| I think you underestimate a bit what postman can do. Just a few
| things: import openapi specs and do pretty complex requests
| with a few mouse-clicks, supports various auth mechanisms
| (oauth/jwt/...), allows for some scripting, run mock versions
| of an API spec, generate request code for various languages and
| frameworks, and yes, copy a request you created with
| point&click as a cli curl command.
|
| On top of that, you can easily save and share this in teams.
| the_gipsy wrote:
| You're proving the point, nobody would pay a monthly
| subscription to use curl over netcat.
| [deleted]
| sxg wrote:
| Are you sure? Or do people just not have the opportunity to
| pay for curl?
| matt_heimer wrote:
| If you want the opportunity you can go to
| https://curl.se/donation.html
| kajaktum wrote:
| Its not obvious that CURL would be as popular as it is if
| it started with a pay to use model. Maybe it never got
| the attention it has and never got popular?
| the_gipsy wrote:
| Yes, people would just script netstat. I mean the
| argument is getting ridiculous, as another sibling points
| out, cURL would be nowhere today if it wasn't FOSS.
| np_tedious wrote:
| I think sharing among teams is supposed to be the draw. I don't
| really see the point either
| SideburnsOfDoom wrote:
| If you use a tool whose state is stored in text files, then
| git solves the "sharing among teams" issue for free. So it's
| a paid solution to an invented limitation.
| devoutsalsa wrote:
| My team uses Postman, but we largely stick to just sharing
| curl requests. No one seems interested enough in the team
| functionality to figure it out.
| awill wrote:
| So your team is the perfect candidate for the paid version,
| and doesn't see the value.
|
| I agree with others that Postman created limitations just
| to justify a paid version. Those types of services/apps
| rarely succeed.
| devoutsalsa wrote:
| We have the paid version. People just can't seem to
| bother using the premium features.
| petard wrote:
| Maybe it is the same good idea as Slack is just a GUI on top of
| IRC
| wolpoli wrote:
| Last time I looked at Postman and Insomnia, the exported xml
| files were not compatible with each other. I hope we end up with
| data portability at some point.
| surajs wrote:
| brian_herman wrote:
| I wish they would support soap.
| 2Gkashmiri wrote:
| i have to ask here since this is about api. i have a use case
| whereby i have to do some sort of "one time password" processing
| via email. the otp gets on the email. that email is forwarded to
| a "server" which regexes the body and outputs the OTP and some
| other fields like email address forward. at the same time, the
| user would be using a browser extension and once that detects the
| user has requested OTP, a request would go to the "Server" which
| would match the two requests and send the browser extension the
| necessary OTPs.
|
| i know the whole privacy thing around it, this is a small project
| and the OTPs themselves arent tied to any banking and stuff, just
| office work..
|
| then there is another thing about captcha proxy using those
| captcha services. i do not want users to directly access the
| captcha api key, they should use internal keys for accounting
| purpose.
|
| i have found "fusio" on github but it is terrible at explaining
| how to proceed and the documentation isnt that great
| newusertoday wrote:
| if you use gmail you can write appscript to extract the
| otp(regex part), service that sent the otp and timestamp when
| you recieved the mail to your "server" via post request.(i am
| assuming you know how to make a post request with dummy data
| using curl or javascript)
|
| you can use django/ruby on rails or golang for your server,
| authentication is available out of the box for django and there
| is great documentation for api.
|
| I am not clear on what you intend to do with captcha so no
| comments.
| 2Gkashmiri wrote:
| i plan to use a mail server independent of google so i can
| manage more parts of it without being subject to limitations
| of the email providers and because i am not going to "send"
| any email, there isnt even a problem of deliverability.
|
| my question is that does there an appscript alternative that
| i can self host on my server..
|
| so you are saying
|
| email server> appscript(alternative)>django><browser ?
|
| the OTP is for lazy people who cant be bothered to check
| their multiple emails for OTPs. nothing sinister...
| newusertoday wrote:
| there are three parts to your problem 1. recieving mail and
| processing it. Since you are planning to host it by
| yourself answer would depend on what are you using for
| hosting. Solution can be as simple as reading a file(i.e.
| recieved mail) and extracting relevant fields using
| whatever language you know python/shell ecript etc. This
| part would be highly specific to what you use as your mail
| server.
|
| 2. server that responds to the api request made by chrome
| extension. This is where you can use django it would
| provide basic security as well as cater to the api request
| made by your extension here any server would do as your use
| case is quite simplistic. It should be few lines of code
| depending on your familiarity of language.
|
| 3. Chrome extension this would be in javascript.
|
| are you developer? or do you have access to developers? if
| yes than it should be straightforward.
| nXqd wrote:
| Does the postman collection work with this hoppscotch. If it
| doesn't then it's quite annoying that you have to retype all of
| those.
| ticklemyelmo wrote:
| Why are all of the API clients so intent on storing all your
| requests and environment config in the cloud?
|
| We would keep a directory of relevant collections and
| environments inside all our application repos, so they would
| simply be committed along with the code, be versioned, included
| in PR reviews, etc. But it looks like _all_ of the popular REST
| client tools use some hidden cloud services. This is also
| terrible from a security perspective, since environment variables
| are likely to include secrets.
| politelemon wrote:
| It's easier to monetize that way. They manage the convenience,
| your team pays them money. Once your team is using it, you're
| soft-locked in to continue using it.
|
| Yes, agreed on the security perspective. It's not a secure
| tool. For that you should consider a desktop client (eg
| Fiddler) rather than a browser based client
| XorNot wrote:
| Fundamentally I've really given up on tools like Postman.
|
| A Jupyter notebook with python and requests is a much more
| flexible solution which turns into your actual automated test
| suite much more easily.
| debarshri wrote:
| Fun fact. Hoppscotch was also known as postwoman [1] They are
| really going after Postman's business.
|
| [1]https://pitchbook.com/profiles/company/489006-55
| asim wrote:
| Hoppscotch raised money right? Unfortunately the nature of most
| VC backed companies is to believe features are the answer to
| monetization and enterprise adoption. These things quickly become
| bloated because of that. So people slamming Postman, yes the
| product has become a Swiss army knife, but they're trying to
| figure out how to scale a business long term and that often means
| leaving behind free users. Don't be surprised if hoppscotch does
| the same.
| datavirtue wrote:
| A bloated mess of a tool is going to get dropped by developers.
| The last thing we need is a something like postman hamming up
| our day.
|
| Logging in, online this, cloud that. No thanks. The end for me
| was when it took me a half hour of failed google searches to
| import an old collection. They are going to lose enterprise
| inertia, it has already started.
| foverzar wrote:
| Doesn't seem there is a way to generate curl statement. Pity.
| Sholmesy wrote:
| There is, drop down at the the top (next to the request).
| lux wrote:
| LOVE seeing websockets in there already!
| querez wrote:
| The website does does not show anything if javascript is
| deactivated. Could at least show SOMETHING to tell me what I'm
| looking at.
| MarcellusDrum wrote:
| The website linked is not a landing page, but the actual tool,
| which is based purely on JS (Vue and Typescript to be precise).
| Here is the Github repo:
|
| https://github.com/hoppscotch/hoppscotch
| querez wrote:
| Thanks for pointing that out!
| lnenad wrote:
| I wrote https://github.com/lnenad/probster using GTK3 so it can
| be used on weak machines, top ram usage was 40MBs in my
| experience. It's pretty barebones though.
| unfocussed_mike wrote:
| Awesome.
| ducktective wrote:
| Thanks for existing...Not that I need a gtk3 postman
| alternative right now but for caring about resource usage and
| performance.
| lnenad wrote:
| lol, thank you, it really is annoying that for such a simple
| functionality you need so much resources.
| ractive wrote:
| I often use the RESTED firefox extension, which covers like 90%
| of my adhoc http request needs:
| https://github.com/RESTEDClient/RESTED It's pretty slim with no
| bells and whistles.
| izyda wrote:
| While many know the HTTPie CLI product, they also have a desktop
| and web product now
|
| Check out;
|
| https://httpie.io/product
| switchbak wrote:
| HTTPie for Web & Desktop is in private beta. Subscribe to the
| newsletter below to be notified when it's ready and receive
| your early access invite.
|
| Not particularly available right now.
| silentguy wrote:
| I see mac apps available for download here:
| https://httpie.io/download . Web app is in private beta.
| CryptoBanker wrote:
| The desktop apps still require a login that requires access
| to the private beta.
| th3h4mm3r wrote:
| Does it do parallel requests with custom parameters? Postman also
| today suffer at that point.
| dsego wrote:
| Is there a command line tool or editor plugin where I don't have
| to specify parameters, learn all the options. Instead I would
| just point it to an "http file" with http syntax and it "runs"
| it. Meaning the file contents are the http request that I want to
| send, eg GET / HTTP/1.1 Cookie:
| Accept: text/html,... Host: news.ycombinator.com
| Accept-Language: en-GB,en;q=0.9 Accept-Encoding: gzip,
| deflate, br Connection: keep-alive
|
| And the I can just run it like so `http myRequest.http` There are
| some decade old sublime text plugins that claim to do this, but
| none of them seem to work anymore, from what I'm seeing.
| Extropy_ wrote:
| I know IntelliJ IDEA Ultimate does that, not sure about any CLI
| tools. But it does look like you could use netcat to do that,
| for example:
|
| cat myRequest.http | netcat example.com 80
| seanw444 wrote:
| Emacs has a handy plugin for exactly that.
|
| https://github.com/pashky/restclient.el
| User23 wrote:
| There are also good options for GraphQL. I particularly like
| embedding the calls in org mode[1]. There's similar
| functionality for REST[2].
|
| [1] https://github.com/jdormit/ob-graphql
|
| [2] https://github.com/alf/ob-restclient.el
| iib wrote:
| Emacs can do this [1]. AFAIK, this is what inspired the vscode
| extension.
|
| [1] https://github.com/pashky/restclient.el
| hultner wrote:
| Yeah, nc 80. Or openssl s_client for https, you can also run
| through stunnel.
| WaxProlix wrote:
| Can't `nc` (netcat) do (basically) this? `cat myRequest.http |
| nc <hostname> <port>`
|
| Not robust, but it comes with all systems for free.
| mkdirp wrote:
| Now do HTTPS.
| Kwpolska wrote:
| https://serverfault.com/questions/102032/connecting-to-
| https...
|
| openssl s_client -connect example.com:443
| matt_heimer wrote:
| From a CLI you run into issues with `nc` and the like
| supporting https. You can get close with `curl` since it has a
| -H option that allows you to provide headers in a file.
| curl -v -H @request1.txt neverssl.com
|
| With a request1.txt header file X-Header:
| mine User-Agent: bob
|
| Will generate a request of > GET / HTTP/1.1
| > Host: neverssl.com > Accept: */* > X-Header:
| mine > User-Agent: bob
|
| You end up needing to know 3 options. -X <METHOD> to specify
| the HTTP method, -d @<file> if you want to send a request body,
| and -H.
| smusamashah wrote:
| You may also want to look at Prestige
|
| https://prestigemad.com/
| https://news.ycombinator.com/item?id=27412445
| eriol wrote:
| You may want to look at hurl: https://hurl.dev/
| [deleted]
| cbcoutinho wrote:
| Yes this exists as a VS code plugin
|
| https://marketplace.visualstudio.com/items?itemName=humao.re...
| andiareso wrote:
| Second this one :D
| mnembrini wrote:
| You want this https://github.com/bayne/dot-http
| kbd wrote:
| Very cool, hadn't heard about that tool. Do you think that's
| more powerful than simple shell scripts around
| HTTPie/xh/curlie?
| clajiness wrote:
| If you're a Mac user, check out Paw (https://paw.cloud/).
| unfocussed_mike wrote:
| Paw is _beautiful_ but it has no GraphQL tooling at all, I
| think? (Just native POST requests etc.)
|
| (Unless there's a beta you're using?)
|
| I use Insomnia but I am quite keen to start building myself a
| local-cloud-based toolset so I can reduce my reliance on a
| single machine, so Hoppscotch looks interesting.
| innocentoldguy wrote:
| Paw kind of supports GraphQL. It doesn't offer any kind of
| hints for field types or auto-complete features, but you can
| use it to make GraphQL calls.
| unfocussed_mike wrote:
| Great. They don't mention this on the main website but I
| hadn't spotted it in the blog until now -- thanks for this.
| jasonlotito wrote:
| I mean... GraphQL is over HTTP pretty much[1]? Any HTTP
| client will support GraphQL. Is there something I'm
| missing with this exchange?
|
| 1. https://graphql.org/learn/serving-over-http/
| theturtletalks wrote:
| Hoppscotch and other gQL clients allow introspection on
| the GraphQL schema so you get a API reference out-of-the-
| box. Makes it super easy to write queries and mutations.
| liyasthomas wrote:
| GitHub: https://github.com/hoppscotch/hoppscotch
| tambourine_man wrote:
| I just use curl. Never understood the appeal of such tools
| dan1234 wrote:
| It's easier to do the OpenID authentication dance with a tool
| vs curl (especially when doing PKCE requests), and I use
| Postman to build up some documentation for my APIs.
| blueflow wrote:
| There are already many tools for many things in the Linux base
| userland, installed per default. Mankind could save many CPU
| cycles and developer days if we'd be able to read the existing
| documentation and learn to use them.
|
| But instead we are here, people are baffled if projects run on
| bare Debian with no extra dependencies as if it was some kind
| of magic.
| cytzol wrote:
| I use cURL a ton too, for when I want to make a one-off
| request, examine the response, and then throw it away. Here are
| some reasons why I'd reach for a tool like this:
|
| * I want the history of every request and response to be saved
| by default, so if I ever need to look back to one I know it's
| available
|
| * I'm sending several similar requests and I want them to share
| a set of variables, or, I want something in the response of one
| request to be used as a parameter when sending another
|
| * I want to set a URL parameter with a bunch of symbols in
| without worrying about quoting
|
| * I have so many types of requests that I'd like to organise
| them in a tree
|
| * The JSON returned in a response is absolutely massive and I'd
| like to expand/collapse subtrees instead of viewing the whole
| thing as unhighlighted text
| jillesvangurp wrote:
| Same here. Curl, bash, jq, etc. But of course not everybody is
| comfortable on the command line. I notice a lot of frontend
| developer seem less familiar with that stuff, for example. Non
| technical people are typically also not comfortable with UI
| based tools for this.
|
| The exception for me is stuff like graphql. It's nice to have
| some code completion for that since it is so fiddly and
| verbose. Likewise, I use Elastic's dev console to interact with
| Elasticsearch/opensearch.
|
| Otherwise, I avoid doing a lot of manual requests to anything.
| Most of my systems end up having some kind of admin UI. I don't
| want people faffing about with curl commands to do routine
| stuff and then messing it up and creating a mess. That just
| doesn't scale. Building a UI usually implies building a good
| api client. I've also scripted together a simple cli in the
| past with just curl and some bash commands. A bit more work but
| nice once you have it. The downside of cli is that only techies
| can use it. Having a ui means you can hand off responsibility
| to less technical people or customer support. So that actually
| reduces my workload. Postman, SoapUI, and whatnot are too low
| level for that. And once you have a decent API client, you can
| also use it to write good tests that don't just copy/paste a
| lot of http stuff around.
|
| I once had a test engineer that insisted on writing tests using
| SoapUI (which as the name indicates was originally intended for
| testing SOAP stuff but eventually evolved to do REST stuff).
| Big PITA to deal with these tests because they were highly
| flaky and he just copy pasted shit around in SoapUI so it took
| ages to fix anything. Also asserting anything useful was also a
| bit limited. Basically any trivial change you made to the code,
| dozens of those tests would fail. The more tests he added, the
| worse it got. We eventually replaced those tests with a proper
| API client and integration tests that we could actually
| refactor in a sane way and run concurrently. The result more,
| better, and faster tests.
| dabeeeenster wrote:
| I interviewed Liyas recently for our podcast - their Github
| growth rate has been really incredible. Shameless plug!
|
| https://flagsmith.com/podcast/hoppscotch-liyas-thomas/
___________________________________________________________________
(page generated 2022-02-28 23:00 UTC)