I use hurl [1], a text-based HTTP testing tool. It's like the proprietary one that jetbrains ships, but as a CLI tool and can be perfectly integrated into CI. It is based on curl, as the name suggests.

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

Hi nikeee glad to see you here!

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

Learned something new today. Thanks!

HTTPie (the CLI version) is great and was a big improvement for me over cURL.

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.

https://github.com/ducaale/xh

Again recommend the HTTP client in the Jetbrains IDEs for this. Everything is text based and goes neatly in your repo. You can pull in npm and script against responses and for tests if you like. It’s also constantly updated.

For VSCode, there's https://github.com/AnWeber/vscode-httpyac

Isn’t it only available with the ultimate version?

The JetBrains IDEs don't have an ultimate version, I think you're thinking of VSCode.

Yes they do IntelliJ IDEA Ultimate and IntelliJ IDEA Community are separate IDEs.

> The JetBrains IDEs don't have an ultimate version, I think you're thinking of VSCode.

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

The OP most likely meant the paid version of JetBrains IDEs

VSCode does not have an ultimate version.

Why did you even link to this weird GitHub repo with only a README that links to their home page?

because it's not open-source but fools the users into thinking it is.

As the first paragraph in the README says, we use the GitHub repo to host releases and issues.

I understand why/how you use GitHub, but I don't understand linking to an empty repo from a HackerNews post. The product home page would have worked better.

Whoever posted it thought otherwise.

https://gchq.github.io/CyberChef - is my overkill go to for this task - it makes me feel like a Secret Agent while testing posts and gets.

A surprising number of these tools don't support HTTP/2, sadly.

That includes HTTPie, Postman, and RapidAPI, last I checked.

Probably isn't easy to do with Electron-based apps...

I don't see why. Electron's based off of Chromium, which should be able to speak http/2, no?

You cannot control the HTTP version in a webpage with JavaScript... The browser has complete control over selecting an appropriate version.

But since Electron includes nodejs, it should be possible, but probably not that easily.

I don't know what the problem is precisely, but I suspect the issue lies somewhere other than the browser's standard HTTP version negotiation.

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.

Perhaps better known for their CLI tool which I use as a replacement for curl.

I know this is about Desktop HTTP testing but have anyone experimented with command-line HTTP testing?

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.

Why do none of these tools let me store data in a git repo? I want everyone on the team have the same setup and keep in sync with API changes.

Check out bruno[0]. It's decent for what it is, replaced Insomnia when they made some dumb moves a week or so ago and is completely file based though I wish there were ways to make less files. I don't want to check in so much stuff every time I make a change. It's still missing a few features but the dev seems passionate and there's frequent updates

[0] https://www.usebruno.com/

Do you have anything you can share on what King did with Insomnia recently?

There was some discussion and links on https://hackertimes.com/item?id=37708582 recently - tldr, Insomnia now requires a cloud account and can’t run purely locally.

See also https://github.com/Kong/insomnia/issues/6606

Something like hurl?

https://hurl.dev/

You can try bruno - https://github.com/usebruno/bruno.

Because they are trying to monetize that later?

that is exactly what’s going to happen.

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.

Kreya [1] can do that. It is even optimized for it, so that diffs should be perfectly readable.

[1] https://kreya.app

I know this is more of an information security oriented tool, but Burp Suite by Portswigger is an amazing HTTP proxy. Over the years, as an information security consultant, I have used it quite a bit when writing my own little web apps to diagnose and debug any issues. It isn't a proper software testing tool in the DevOps sense, but if you are manually debugging and poking at a larger API there isn't a better tool out there IMO.

On the subject of APIs, anyone knows how to split Open API 3.0 specs into separate files? I'm using swagger-cli but it is abandoned lately.

You can start writing multiple OpenAPI files and merge them with tools like openapi-merger (https://www.npmjs.com/package/openapi-merger). Is that maybe what you want?

* I note this is not splitting one large one into small, but the actually starting with smaller ones, as the other commenter suggested

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)

https://github.com/mikefarah/yq

I use CUE(lang) for things like this

Beautiful. Didn't know something like this exists. Reminds me of Katai[0]

[0]. https://kaitai.io/

CUE is indeed a beautiful language, will get those mind juices flowing for sure!

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

Why is the license for this GUI tool so different than the license for their command line tool? The source isn’t even in this repository.

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.

> Why is the license for this GUI tool so different than the license for their command line tool? The source isn’t even in this repository.

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.

>The desktop app is not ready to be open-sourced yet.

There is no such thing as code being ready or not to be open-sourced.

Are you the @prmoustache on GitHub with zero public repos?

911? good, hi. I'd like to report a murder.

nope but surely a fan of the same comic.

Yet another closed source electron crap. No thanks.

Electron is Flash for the Desktop[1]. It is cheap to implement. It wastes resources, doesn’t integrate natively and is a security problem.

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 only a tradeoff because for some reason we decided, collectively, that writing native apps is impossible.

We did multi platform apps when we still called them programs. We used some cross platform toolkits with either cross platform UIs that felt out of place everywhere or a layer that hooked to a common subset of the native ones, with maybe an option to go really native. We wrote C or C++, mostly.

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.

Microsoft lost the plot with their app frameworks for local apps so electron not so bad and gets you cross platform

Which apps in this space are native? I vaguely remember paw.cloud (RapidAPI) being native, but that was before the rebranding.

Yes, paw was (is?) a native macOS app.

Kreya isn't based on Electron, but uses the native WebView of the OS.

Yes, Paw is native.

For an app that is all about web requests and API testing it actually makes a lot of sense.

And again no support for websockets all these tools are just basic implementations of what postman was doing at the beginning. Do we have to go through all of the feedback again? Why are you not scoring through the docs and forums of other tools and try to learn from it? I mean you have no moat at least have convenience.

oi, mate! what opensores is this? where's the source?

Their project that I am most familiar with is there CLI https://github.com/httpie/cli

Going slightly off tangent to ask about something.

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.

I've seen "HTTP transcript" used in this sense.

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

The problem with HAR file is that it is by definition an archive format, and not design to be human-readable.

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.

> There seems to be lack of a single word in English to describe this except the long phrase above. Anyone has good suggestion?

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

Thanks for the response. Does the client (desktop app) support exporting the full exchange as txt? I would switch to HTTPie Desktop if this is supported.

We show the request/response in two separate panes, each with a menu offering Copy and Download actions. So it’s possible; it’s just a matter of multiple clicks.

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.

Thanks. So it is the same amount of steps as I have for Chrome now.

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

It’s a good idea — we’ll look into making it as simple as in HTTPie CLI. Thanks for the feedback.

The last thing that scratched this itch for me was Dredd https://github.com/apiaryio/dredd .

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

In this case I recommend capturing your whole traffic for an endpoint, e.g. with MITMProxy as you are doing your requests. Often I test SPAs and do so by turning on MITMProxy with some filtering, using the app in the browser normally and then saving the traffic capture. Later I can even generate API docs from that. Regarding terminology, I'm also not sure how you'd describe that.

Yes. I usually use MITMProxy for mobile and Chrome for desktop for such tasks. The other comment suggests the term "exchange" which I like.

FWIW, I’m fond of a testing technique where the entire “exchange” of a request/response for a HTTP handler test case is committed to the repo.

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.

You probably don't need all of them. But we've created HTTPie Desktop based on the feedback of HTTPie CLI users over the past decade who wanted to have the same comfort on the desktop as they do in the terminal. The feedback we've been receiving from devs actually using has been incredible.

100s of endpoints with various evolving payloads across 100s of developers.

The problem space is shared documentation, not 'make http request'

I think OpenAPI is a better choice for this kinda stuff. The API docs are the source code and less lock-in that way. Devs can still use the tools they want.

OpenAPI only describes the endpoints. Ultimately people want examples and to test their endpoints collaboratively rather than just see a description of it with the fields it accepts. Actual use cases and a proper flow of being able to authenticate and use that token to call the other APIs and check the responses is what people seem to want more than a "dumb" curl GUI

OpenAPI has example capabilities built in and there are many interfaces for turning the specs into WebUI

https://swagger.io/docs/specification/adding-examples/

I've been using elixir LiveBook as my http client. It works flawlessly

You could do something very similar with jupyter

One must ask themselves why a REST testing tool has venture capital and needs to be closed source (despite their website proudly claiming "Open source"). I'll pass on installing this onto my computer.

Very well PUT (pun intended). Actually, isn't this how we exactly got where we are with Postman?

> closed source (despite their website proudly claiming "Open source")

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.

You gave this exact same answer to me in your Discord a year ago. If nothing sketchy is going on why not just open source the thing?

At a minimum you should remove the banner at the bottom of the page claiming it's open source.

> You gave this exact same answer to me in your Discord a year ago. If nothing sketchy is going on why not just open source the thing?

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.

Good on you for altering the page. I very much hope to see the desktop client become open source soon, as I would very much like to use it. Best of luck with the project.

I don't understand; why do you think it is "sketchy" to try to make a living out of software?

(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 understand; why do you think it is "sketchy" to try to make a living out of software?

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.

> 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

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! ;-)

> having a github repo with no code just to attract devs and look open source-y

It's an HTTP client. The client codebase is here:

https://github.com/httpie/cli

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?

We started httpie/desktop as a separate codebase but are working on unifying it with httpie/cli and our cloud to avoid multiple implementations by extracting a shared runtime that will be used everywhere. One of the interesting challenges here is that HTTPie Desktop is written in TypeScript while the rest is in Python.

Thanks, of course, that makes sense. How are you planning on doing it -- use a language like Rust that can easily be called from both and packaged? Or rewrite the CLI in Typescript?

We have a PoC where the runtime is implemented in Python and the Electron and web apps use it through https://pyodide.org/. Still exploring but looks surprisingly viable.

Any recommendation on open source alternative?

I've been using https://github.com/bayne/dot-http but https://hurl.dev/ seems more full featured.

Neither of these have the convenience of the original Postman GUI and aren't really alternatives.

Bruno seems like a good up and coming candidate. Found about this one after all the insomnia drama a couple weeks ago

https://github.com/usebruno/bruno

For creating requests the GUI of postman is way over the top. HTTP is so simple, why not just write that directly in a literate format you can checkin to a repo? For actually running the requests though I agree a gui is nice. I actually use dot-http as an embedded tool in a browser extension. They're still alternatives, just not in the style you're used to.

> HTTP is so simple

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.

https://github.com/ArchGPT/insomnium - and soon with local llm support

disclaimer: I'm the maintainer and my day job is fine-tuning llm

p.s. I will always keep insomnium 100% local & FOSS

Restfox works great for me. Might require installing a browser addon to circumvent CORS protection in order to run requests against localhost.

Why doesn't Github have some kind of policy about projects pretending to be open source and effectively acting as an ad on Github?

It would be a little funny that GitHub, a proprietary code hosting platform, suddenly cares that proprietary software uses it to host bug reports or other assets. This isn't the first project I've seen that is nothing more than a README and exists simply for people to file issues. e.g. there is https://github.com/cursive-ide/cursive

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

As the first paragraph in the README says, we use the GitHub repo to host releases and issues.

(It’s not open-source yet as we first want to get the product, architecture, and codebase somewhat stable.)

at this page, https://httpie.io/desktop, there's a logo that says "open sores, open hearted, open minded." it's misleading, then. at least remove that part in the page.

That’s a good point. I’ve now updated the website template not to show the image with the slogan on this page. Thanks for the feedback.

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

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.

Hi Daan,

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

Hmm. That is very misleading. Their footer talking about open source is referring to their cli (which is very good btw)

This might be an oversight just need to fix their marketing page

Do you mean HTTPie also raised venture capital or just in general? If it is HTTPie, would you have a source?

Not doubting. I'm compiling a table with Postman alternatives, VC-backed is on column and I like to add sources where possible.

> We’ve raised a $6.5M Seed Round from Coatue, Blossom Capital, the founders of Intercom, Checkout.com, Monzo, etc.

— https://httpie.io/about

> $6.5M

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

Nice, thanks for sharing your wisdom. And still insane they need that much money, we all have examples here of businesses that succeeded without having to raise millions of dollars

Ok, but I guess httpie are raising money in an environment where investors are wanting to invest a lot of money, and they thought "why not, it will raise lots of exciting possibilities for the business". So I'm still not getting why there's so much criticism from people in this thread. You'd probably have done the same in their situation.

Yeah, but normally taking money from investors means they want growth and a return on their investment which often skews business decisions to get quick money at some point. This often leads to an enshittified product. It seems unrealistic to make millions of dollars in short time in return for a simple product that already exists in many variants even for free. So people believe the product will suffer which makes the users suffer.

> Yeah, but normally taking money from investors [...] often skews business decisions [...] This often leads to an enshittified product.

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.

> Wow, I'm glad we've got you here to point out that the startup model doesn't work!

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.

I reacted snarkily because you appeared to be giving a one-sentence criticism of the entire model of startup investment. Doesn't that seem much too large a topic, and too well-established an aspect of modern economies, to dismiss in such a shallow manner?

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?

> "I'll give you lots of funding to start a software company

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.

They're not "making a REST testing tool". They're trying to start something called a "business". This has been a prominent feature of human society for many centuries. People do it to pay for their lives and their family's lives.

It's next in line after Postman. Used it for years, liked it, now it's enshittified. I'll use this one until the endless cycle repeats.

Because they're trying to make a living from software? And why the fuck, exactly, should they not do that? Reread your comment and perhaps you'll see how insufferably entitled, as well as naive, it sounds.