HTTPie Desktop: cross-platform API testing client for humans
github.com
github.com
What I was also playing around with is using it as a scripting tool. Comments are made using #, so you can add a shebang to a file, make it executable and use it as a lightweight script for HTTP stuff.
[1]: https://hurl.dev
As maintainer of Hurl, I'm very happy that HTTP clients is the new place to be! I'm not able to write a text editor, but a tool relying almost entirely on curl is in my reach...
However, I ended up switching to xh[1] as it's significantly faster and I prefer its output.
Although I might give this Desktop version a try for more complex APIs.
This is not true. I installed intellij community, searched through it's plugins for http clients, and Jetbrains' plugin shows up all greyed out with the message "ultimate only".
That includes HTTPie, Postman, and RapidAPI, last I checked.
But since Electron includes nodejs, it should be possible, but probably not that easily.
I think this because, when I was testing Postman, if I set up my web server to support only HTTP/2 in the TLS ALPN, Postman didn't fall back to HTTP/2, it just failed.
If the standard browser negotiation were happening in Postman, I would have expected my setup to force HTTP/2, even if it generally wanted HTTP/1. My guess is on the Postman side, they simply don't support H2 in the ALPN.
I admit, I know nothing about Electron, so maybe there really is some weird limitation. But I think it's more likely Postman just didn't want to write the code to support HTTP/2. Most API users don't care about the transport; but I maintain a web server, and learning this rendered Postman useless for me. For now, it's curl or Insomnia.
I recall having a good experience with https://github.com/grafana/k6 some eons ago.
It's geared towards load testing in JS but it also allows you to check HTTP body, headers, etc.
the ones that aren’t Silicon Valley businesses currently in their “growth” phase will openly let you save off your entire collection of queries as plain text, and will ideally handle storage of this in git for you. After “growth” is “capture” where they turn free users into paid ones.
The number of people who get foaming-at-the-mouth angry over Microsoft because they did this in the 1990s and who also ignore the hundreds of companies doing this as part of the startup playbook is staggering.
I store different api logic in their own files. Then I use yq to stitch them all together. After which, I use openapi-generator to make a yaml output.
https://gist.github.com/freshteapot/3637e8d2b5ecdf01b7d25246...
- yq version 3.4.1 (Worth noting, the example uses an out of date yq, so a few modifictaions might be needed)
[0]. https://kaitai.io/
There is more work to be done on the codec implementation, but if you just want to split yaml/json across files, CUE is a great option
You might also like my project, built on CUE: https://github.com/hofstadter-io/hof We have a TUI where you can explore and work with CUE, JSON, Yaml
There is 0% chance that this will avoid the route that POSTman and Insomnia have paved.
WTF is it about these tools that the creators think will make us tolerate the sudden switch from free to paid? I am dead tired of watching this play out over and over.
The desktop app is not ready to be open-sourced yet.
> There is 0% chance that this will avoid the route that POSTman and Insomnia have paved.
HTTPie has been around for 10+ years, and the new desktop product is built around the idea that we can do much better than the incumbents (from a much simpler interface and more pleasant UX to a more aligned set of incentives supporting incognito, free, as well as paying users/companies).
> WTF is it about these tools that the creators think will make us tolerate the sudden switch from free to paid? I am dead tired of watching this play out over and over.
What Postman and Insomnia did is not cool. But that does not mean it’s unavoidable. Even though it complicates development, we’re local-first from the very start. Accounts and sync are optional layers on top of it.
There is no such thing as code being ready or not to be open-sourced.
As usual the industry safes money and the customer has to pay for the memory. I’m sick of applications which doesn’t adapt to HiDPI (automatically) and consume 500 MB of memory whereas a C/C++, Rust or even Python with Gtk or Qt will consume about 50 MB.
Aside from that Postman has become unusable because the company behind it want to earn „now“ money. I don’t say HTTPies UI is bad it just not what users want.
[1] http://josephg.com/blog/electron-is-flash-for-the-desktop/
It's a trade-off.
Without Electron and the likes, a fraction of the apps that are now almost effortlessly cross-platform would exist for Linux, for example.
Then HTML became that common subset of the UI and the browser JS runtime and rendering engine replaced the cross platform toolkit. Bloated, not optimized for space and time as it could be, etc, but very convenient.
Kreya isn't based on Electron, but uses the native WebView of the OS.
I often find myself in a situation when testing API to request for "API request and API response", including header, body, etc, the full complete information. This helps to identify any issue with it, and keep the full record for the future reference (it happens a lot that I need some information on the old API behavior weeks later).
There seems to be lack of a single word in English to describe this except the long phrase above. Anyone has good suggestion?
It goes without saying that this is a hard requirement I have for any API client but sadly most ones I tried always lack some information somewhere.
If you mean the request and response message pair, we call it "exchange" [0].
> It goes without saying that this is a hard requirement I have for any API client but sadly most ones I tried always lack some information somewhere.
Both HTTPie Desktop and HTTPie CLI allow you to see the entire exchange. In the CLI, you can use the --verbose flag [0]. In the desktop app, there’s a “Request” tab.
They both also support previewing the request without sending it. The CLI has --offline [1], and the Desktop has a live preview feature [2].
[0] https://httpie.io/docs/cli/what-parts-of-the-http-exchange-s...
[1] https://httpie.io/docs/cli/offline-mode
[2] https://raw.githubusercontent.com/httpie/desktop/master/.git...
The desktop app also allows you to copy a corresponding HTTPie CLI command, which you can then enrich with --verbose, run in the terminal, and more easily copy the whole exchange output.
Please do consider adding a feature to export everything in one shot. It would save people like me a lot of clicks (for a lot of APIs across different environments).
But writing tests in markdown is not for everyone. Here are few examples of what "test files" look like https://github.com/apiaryio/api-blueprint/tree/master/exampl...
I didn't use in for two years so I can't say how well it works today (it doesn't appear to be actively maintained).
If the result doesn’t match what’s in the file, the test fails. You can run the tests with a special flag to update them in place.
It gives great regression coverage on that edge of the system and it can easily be done with a good language HTTP library.
Rather than a general term, though, what you probably want to focus on — especially because you want to "keep a record" — is the common file format used for these: https://en.wikipedia.org/wiki/HAR_(file_format)
(It was created and initially supported by web browsers, but many CLI/GUI dev tools should be capable of emitting HARs as well, often "off to the side" in some logging directory while also presenting separate, pretty info on stdout.)
For these types of records you typically want to store them in internal documentation system which usually consist of markdown or rich text documents for ease of browsing.
Saving it as an attachment is possible, but it would require whoever that is reading it to download and view it inside a HAR viewer (Chrome), a few extra steps.
The problem space is shared documentation, not 'make http request'
You could do something very similar with jupyter
With that said, Codeberg has a strict policy of hosting software licensed under an OSI or FSF approved license.[1] They will actually take down repositories that do not follow this guideline.
[1] https://docs.codeberg.org/getting-started/faq/#can-i-host-so...
(It’s not open-source yet as we first want to get the product, architecture, and codebase somewhat stable.)
Can you be more clear? Is the Desktop app going to be open-source in the future? If so, what license?
Do you intend to monetize this product? If so, how?
As a side note: I find it strange that you feel the product is not stable enough to share the code, but apparently stable enough to share the product itself.
>> not open-source yet
> Can you be more clear? Is the Desktop app going to be open-source in the future? If so, what license?
Yes, but have no ETA or license choice yet.
> Do you intend to monetize this product? If so, how?
Yes. We strongly believe in a freemium where both free and premium users are happy. We’ll primarily monetize collaboration and enterprise features without cannibalizing free users. In this sense, we’re inspired by companies like GitHub or Figma. And in our case, free also includes users without an account.
> As a side note: I find it strange that you feel the product is not stable enough to share the code, but apparently stable enough to share the product itself.
Running an open-source project well is not easy and takes resources. Building a great product is hard on its own. Our primary goal is to design and build the best API product possible, so we direct all our energy there for now.
So is email. The simplicity of a protocol has nothing to do with the complexity of the workflow that produces it.
> why not just write that directly in a literate format you can checkin to a repo?
Because nothing I work on in Postman is something I need to check in to a repo. I need to test HTTP requests, and I've never worked with a code base that had raw HTTP requests in it.
> They're still alternatives, just not in the style you're used to.
The "style" is different enough that entire use cases become impossible.
Let's say I want to copy HTTP response headers out of a log in JSON format. In Postman, I can paste JSON (and various other key-value formats) into the headers field, and it automatically parses it for me.
There are a hundred little conveniences like that that require a good GUI.
disclaimer: I'm the maintainer and my day job is fine-tuning llm
p.s. I will always keep insomnium 100% local & FOSS
HTTPie CLI has been open-source for a decade. HTTPie Desktop has yet to be open-sourced. We first want to get the product, architecture, and codebase somewhat stable. As the README says, we use the GitHub repo to host releases and issues.
At a minimum you should remove the banner at the bottom of the page claiming it's open source.
We appreciate your interest, but we never gave an ETA. I do regret having made the intention public, though.
> At a minimum you should remove the banner at the bottom of the page claiming it's open source.
That’s a good point. As I wrote in another comment below: I’ve now updated the website template not to show the image with the slogan on this page. Thanks for the feedback.
(For reference, I work as a software engineer and am also the author of a popular open source project which I give away for free and have put thousands of hours into.)
I don't think the original comment meant that it is sketchy to make a living out of software. I think the issue is the posturing as open source, having a github repo with no code just to attract devs and look open source-y and even sharing it on HackerNews right after the issues with closed source by Postman too. Feels like an "open source alternative", but not really, hence the sketchy accusation.
But this is just how I read it.
It's an HTTP client. The client codebase is here:
Why everyone is getting their knickers in a massive twist because they have an Electron wrapper that they haven't open sourced is mystifying.
I haven't studied the codebase but I highly doubt they are going to have a separate client implementation for the Electron product vs the CLI! They're just trying to create a nice Electron client, in addition to their well-known CLI, and start a business around it aren't they?
As the first paragraph in the README says, we use the GitHub repo to host releases and issues.
Having it on GitHub under the same organization as our other projects that already are open-source is convenient for both us and our users — https://github.com/httpie.
> and even sharing it on HackerNews right after the issues with closed source by Postman too. Feels like an "open source alternative", but not really, hence the sketchy accusation.
The person who shared it is not related to HTTPie.
Given the quality of the discourse here, I almost wish they did not! ;-)
This might be an oversight just need to fix their marketing page
Not doubting. I'm compiling a table with Postman alternatives, VC-backed is on column and I like to add sources where possible.
I'm probably missing something, but it seems insane they need so much money to make (yet another) API testing client.
And I'm guessing it means the company is valued at x billion dollars
If they are based in America, they would be calculating at least, say $200k per year per employee, since they need to pay healthcare etc. So multiply that by the number of employees you want in your business, then add all the other costs, and extend over the period you want the funding to cover.
Wow, I'm glad we've got you here to point out that the startup model doesn't work!
I don't understand why this thread on HTTPie has led to so much low quality teenagerish anti-commercial rhetoric; this is far below normal HN standards.
You asked why there is so much criticism to them taking so much investor money and I tried to explain. I don't understand why you react snarky.
I would also argue many comments are not anti-commercial but anti greed.
Is it greedy to accept large amounts of money that an investor offers you? It had never occurred to me to think of it that way. I think of it as being fortunate to be in a position where someone says "I'll give you lots of funding to start a software company". That sounds to me like an exciting opportunity that's definitely worth taking, but apparently you think it's greed?
But in this case there was a mildly successful company that didn't seem to need that much money to fulfill their business plan. That is the direction I was aiming at. So they took more than they needed (greed) but didn't get it for free, but with expectations from investors that might not align with the original companies goals.
My critique went into the direction of taking more money than your plan needs.