Hoppscotch: Open-source alternative to Postman
hoppscotch.io
hoppscotch.io
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.
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
There’s a VSCode extension that executes REST and GraphQL queries stored in a plain text file. So much simpler and more secure. I forget the name - maybe REST client?
yes. `humao.rest-client`
Disclaimer: I‘m one of the creators of Kreya.
[1]: https://kreya.app
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
Overall this tool has been my go-to for 3 years now.
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
https://marketplace.visualstudio.com/items?itemName=humao.re...
cat myRequest.http | netcat example.com 80
Not robust, but it comes with all systems for free.
openssl s_client -connect example.com:443
curl -v -H @request1.txt neverssl.com
X-Header: mine
User-Agent: bob
> GET / HTTP/1.1
> Host: neverssl.com
> Accept: */*
> X-Header: mine
> User-Agent: bob
https://prestigemad.com/ https://news.ycombinator.com/item?id=27412445
Your turn: what was the point of asking?
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.
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)?
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.
I was using Altair's desktop app to handle CORS, but may switch to this set-up.
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.
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.
https://marketplace.visualstudio.com/items?itemName=rangav.v...
You can build tests in it that can be run in automation via Newman.
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.
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.
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?
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.
No, you were saying they'd be better off doing it. 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?
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.
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.
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.
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.
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).
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.
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
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.
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.
> 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
HN gets upset when the Winkelvoss brothers do this sort of thing with website, but it's ok when it's OSS?
Check out;
Not particularly available right now.
I still recommend Insomnia or maybe Paw.
(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.
I agree with others that Postman created limitations just to justify a paid version. Those types of services/apps rarely succeed.
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.
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.
https://www.youtube.com/watch?v=H_k8Z8Zq99s
Here's another for Hoppscotch:
When I started using Talend this was not possible in Postman or others. Curious if that's changed.
Too bad.
The Swagger editor doesn't support OpenAPI 3.1 either, which is surprising since the OpenAPI spec was initially ported from the Swagger format.
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...).
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.
is https://github.com/httpie/desktop ? I don't know this project.
Thanks.
And there's a chrome extension so you can proxy requests through your localhost to avoid CORS issues, etc.
A Jupyter notebook with python and requests is a much more flexible solution which turns into your actual automated test suite much more easily.
Update: 16th August 2020 Postwoman is now Hoppscotch
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
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.
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...
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.
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.
• 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
Requests are saved in .bash_history and easily greped from the command line. With fzf, it's addictively good. Responses are not saved, but it's not something I miss, but it could just be a lack of habit of mine.
>• 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
Again, bash, a bit of scripting for me goes a long way.
>• I want to set a URL parameter with a bunch of symbols in without worrying about quoting
That's a good one. I usually end up resorting to a real programing language like PHP or Python when I begin having to scape special characters much
>• I have so many types of requests that I'd like to organize them in a tree
Haven't felt the need, again, could be lack of habit.
>• 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
I usually pipe it to jq or vim
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.
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!
> "Hoppscotch is a ... web based API development suite. It was builtb ... with ease of use and accessibility in mind ... free-to-use ... Open Source
Looks great BTW.