I like this a lot. Happy to support any project willing to reject the usual “success story” of selling out to VCs and turning your product into subscription-based SaaS junk.
I’m the principal maintainer at work of a couple hundred bash scripts that use httpie and jq. I don’t have a huge appetite to redo that work… but this certainly seems nicer!
Very tempting! But, will there be a lifetime version/license? Would rather pay upfront instead of ending up potentially not really using it much for 2 years.
It says "one time payment" but then it says "2 years of updates".
I interpreted that as having to pay a second time two years into the future if I will want another two years of updates then. A bit misleading.
It's similar to a lot of pricing plans out there. For example I purchased Home Designer Pro 2022 a couple years ago for $450 and I can use the HDP 2022 forever. They have, of course, HDP 2024 but I can't use that one. I can upgrade for an upgrade price. However I don't need to upgrade and am happy to just use 2022 for the rest of time.
I myself use Paw [0] because it's native to MacOS, but I'm a little bit worried for it's longevity as it being supported by a SaaS business. But so far it's been great to document API for my personal projects.
the extensions and ability to write your own extensions, or chain request/response values is crazy. when i've switched to linux box from macos last year, paw.cloud (rapidapi) was one of few stoppers for me, that good of a software it is. also not to mention the integration with keychain for credentials encryption was nice.
postman is really bad, nobody should use it. same goes for similar solutions, even this one.
Quickly turning into abandonware. I tried moving my paw library from one computer to another and it crashes opening the file. Had to start from scratch.
I’m envy? I’m hoping for a native GUI application for Linux.
Electron looks ugly, it doesn’t integrate, fails to handle HiDPI usually, in best case it eats a ridiculous amount of memory (factor 5x compared to native) and in worst case it has security issues due to Blink and lot of JS.
The person being replied to was talking about technical aspects similar between the two (functionality like HiDPI and performance) while you're mentioning socially-oriented differences. I would say both statements are true but that what the authors of each statement value is different.
Writing it is just like Flash is a statement that Electron should be dropped and never used by anyone.
Which I disagree with and provide my argument to show that any technical inconveniences parent poster noted, are not enough to say “Electron should be trashed and razed out”.
Damn, I wasn't sure if I cared about another postman/insomnia like tool, but I saw the cute dog logo, and it sold the tool to me. Maybe I am just silly, but that got me. Congrats to the team for developing it!
Layoff happened, and we didn't yet have our postman software in our list of services to remove employees from. This is not Postman's fault.
One person had "deleted" all his collections and workspaces after the layoff to clear his laptop of all things related to our company. After we got an email from Postman saying our workspaces were deleted, I removed the laid off users. Since I removed the laid off user, the "trash bin" associated with them was also deleted. Postman support restored all the collections but the "environment" was gone. Which was all of our QA test keys, etc...
Our Postman collections are still in shambles after that, and we don't have any employees to manage it anymore. While I totally don't hold Postman accountable - there is definitely a reason why "no-cloud" is a good way to go with these kinds of tools.
It makes no sense in the first place for such a tool to even need a login functionality and cloud saves...
What's really needed to store information about a few http requests? Maybe a few kilobytes. I never understood it and I particularly don't understand how any company could fall for that. If they instead invested in teaching their engineers how to use curl even that would have paid off more.
The benefit of using postman is that you can open the app, see your (shared) collections, easily change the params and hit send. Can curl be used like that?
Of course you can. You can use any tool that lets you write down commands, run it, and edit it. Shells, editors, interactive notebooks like Org Mode, etc. The beauty is that it's just text that you can copy and paste between your tool of choice. You're not locked in to a single tool.
It's not very fun to run the auth call, then copy and paste the access token to the next call, and have to update all of your curl cmds all the time... Even if you use env variables, that's a horrible way to use env variables.
You’re making the case for automation, which happens to be something the shell excels at. Use unexported shell variables or command substitution (e.g., “$(pbpaste)”). Directly use the result of the auth call without going through the clipboard if possible. Create a shell script if shell history isn’t enough. Use interactive notebooks if you need something more advanced. The possibilities are infinite.
If I understood correctly, you claimed that saving requests, modifying it, or parametrizing it was somehow more cumbersome to do with curl than with a GUI. I was just pointing out that the shell is literally designed for all those use cases. And human users don't interactively use curl without a shell.
Also, using curl and the shell allows you to progressively iterate. So "write a script at that point" was kind of the point. Though you don't need to go that far to just feed authentication info.
GUI solutions don't have endless possibilities. You start and end with the exact same tool. The clicks and form fillings can't easily be copied around and iterated on unlike commands in a REPL. You can only perform tasks defined by the author of the application.
I was responding to a claim that essentially boiled down to shells can't parametrize input. How is it even remotely comparable to "the infamous Dropbox comment" to point out that shells can do that better than GUI tools?
Also expecting end users to develop their own file syncing solution on top of FTP is unreasonable. Expecting software engineers to be able to use curl instead of a GUI form is not.
By attitude, you mean not agreeing with every negative comments made about curl regardless of its accuracy. It guess it was just a thinly veiled insult for not being on the "right" side, then.
These tools are Mad Libs for curl commands presented as GUI forms. It does a subset of what curl + shell does while requiring more clicks. The target demographic are people who need to know the tool it's meant to replace in order to do their jobs effectively. That not easier or more convenient in my book.
You're describing the same tool with a much worse UI of recreating the tool yourself (by everyone). There is much value in avoiding that, hence people use integrated tools even with the risks of lock in
What UI do you need to recreate and how is it "much worse?" You essentially type in the same information with curl, but without all the mouse clicks and cursor movements.
Thank you. As soon as Postman asked for a login I uninstalled it and have been curling from text files ever since. My younger coworkers won't drop Postman though. Maybe this will help them switch.
The irony that I switched to Insomnia after Postman started demanding a login... and now I've been actively looking for alternatives (Bruno being on the list) now that Insomnia has done the same thing.
Hi Annop. Thanks for sharing this looks like a good alternative to Postman. I see the company is based out of India (awesome) but wanted to know if the company has gone through the steps needed to sell to teams in the healthcare industry in the US/UK i.e.) HIPPA, SOX2, PCI, GDPR, etc.…
If they never take possession of the user's data into their environment, then most, if not all of those don't even come into play?
Like, that's kinda the whole point of offline-first, local-only tools, you can 100% use them in a an environment you control and take responsibility for. Once you take control of customer's data, there's a whole litany of due diligence that must considered, and often at considerable cost.
While I agree with you and understand that the data is local only, we can only use tools approved by the company. I would like to suggest that my team take Bruno for a 3 – 6 month test drive (since Postman was unable to check the boxes) but cannot without approval….
Your link makes sense, and I believe you.
Have struggled with similar issues. But who knows what the future will bring? Google once said "don't be evil"; Oracle bought Sun. Is there any way you can guarantee your future actions? Contracts, articles of association/company constitution? Maybe setup a trust or charity? I don't think there is.
The "Lite API" mode of current Postman is actually decent, it's the only GUI client I know that supports streaming responses, but you have to use `Content-Type: text/event-stream`. You can't save/share queries, but the local history is decent enough for local development. I prefer it to the Insomnia mutable fixed length saved query implementation for "hacking around" with many different APIs.
Yes, that is that I mean. All the modern "ChatGPT" style API's use this, so if you're building anything that invokes them you can choose between buffering the entire response and modifying/relaying it once complete, or building up a toolchain of streaming-capable utilities.
Of all the http-client applications I tested (Curl, Postman, Insomnia, Bruno), somewhat hilariously Curl has the best support. It will output all 'Transfer-Encoding: chunked' with line-by-line buffering, whereas Postman only supports responses precisely following the `Content-Type: text/event-stream` format (strictly less powerful than curl, as this format requires newlines in between events, and a bunch of overhead on top of that). The others buffer the entire response before displaying anything.
The `Content-Type: text/event-stream` format is fine enough, but I personally prefer to just plainly chunk the responses and let the client choose whether to buffer them into memory and operate on the entire value at once, or interpret them live as the chunks come in. With tools like gjp-4-gpt (Gradual JSON Parser 4 GPT's) you can even interpret partial JSON objects live as they come in and display complex/nested data structures in a generative manner.
Personally I use a lame but effective simple 85.9 KiB static binary filter, a small C program, that removes the chunk sizes so the response is ready for use by other programs, e.g., in a pipe. Buffer is set at 8 KiB.
Is there a way to experiment with one of these streaming JSON GPT APIs non-interactively by just sending an HTTP request, without need for a third party program, an account, use of a Javascript engine, etc.
The unknown length isn't much of a problem for me in practice: GPT's are slow enough that getting a large chunk is almost impossible. I like the idea of the C filter, but in the end you're just piping the data to the program, why add the middle step? Is it to protect against too-large chunks in some way?
I don't know a public API that returns JSON slowly, but you could simulate it by just taking a JSON string, splitting it into 3-5 char chunks, and sending each of those in a `Transfer-Encoding: Chunked` response at ~100ms intervals.
Actually, now that I look at the underlying mechanism behind `Transfer-Encoding: Chunked`, it looks like it's already basically the same as the netstrings. What I'm referring to is the (variable length) contents of the netstring/chunk being sequential slices of a JSON object.
"I like the idea of the C filter, but in the end you're just piping the data to the program, why add the middle step?"
Only for the flexibility to use more programs. Otherwise every program I use to process HTTP responses needs to be able to accomodate chunked transfer encoding. Plus only a minority of sites send chunked responses. Instead, have one program that does one thing: remove chunked transfer encoding.
IIUC, what you want is uniform chunk sizes where you know the size before you send the request.
GPTs sound annoying if they are so slow that they only output a few characters every ~100ms..
Ah I see, I'm working a bit further up the stack from you so the JS runtime handles making the transfer encoding of the response more or less irrelevant, for any response with any encoding you can access `response.text()` and get the entire contents when they're ready, or do something like `for await (const chunk of response.body) { ... }` to work with the pieces as they roll in.
> IIUC, what you want is uniform chunk sizes where you know the size before you send the request.
I don't think so... I don't really want anything! Just a GUI that displays existing HTTP chunked responses as they come.
> GPTs sound annoying if they are so slow that they only output a few characters every ~100ms..
That's perhaps an exaggeration, but in general the speed and "smartness" of the model are inversely correlated.
I'm not really a GUI person nor do I use JS. I'm happy to see HTTP responses in textmode. I tried playing around with Postman and some other similar programs a while back in an attempt to understand how they could be superior to working with HTTP as text files. But I failed to see any advantage for what I need to do. One problem with GUIs/TUIs IMHO is that generally few people write them or modify them. And so users must look around to try to find one written by someone else that they like. Then they are stuck with it, and whatever "options" its author chooses to provide. Whereas with textmode programs, I can easily control all the aesthetics myself. Even when using other peoples' software, if there is something that annoys me, I can usually edit the source and change it.
Best of luck. Hope you can find the right program for viewing HTTP.
It's not open source, but it's in my workflow anyway. The JetBrains HTTP tool is excellent, and has been getting better and better for quite some time.
Great point. I almost wrote, "why use a bru file when more established scripting languages and libs exist for this". But it seems the point here is to bridge the gap between some devs (maybe more junior) on a team that prefer a GUI while also providing a more vc/cli driven experience for the rest of the team.
Not to mention, that bru syntax looks really nice.
I think it's just the nature of how I use APIs. I do discovery with curl then just write a golang CLI for long term use. I'd probably save a lot of boilerplate using something like http-files though.
Hehe, always the same. Popular non-FOSS software always dies in these kinds of ways. That, and that it's Chrome-only, is why I never wanted to use Postman. I've been using RESTED [1] in Firefox happily for quite some time. Although I don't use it that much since unit tests and Django Rest Framework's web UI is usually sufficient for testing and debugging.
Can't echo this enough. Thank you! Beyond just the login reqs from Postman, the whole Postman UI has become an overcomplicated mess in my opinion. I just want something simple to make remote HTTP calls. I can understand adding some useful extra things like variable interpolation and separate environments, but beyond that, Postman went way off the "enterprisey" deep end.
They locked users data behind a login screen a week after postman, then had a half assed "sorry you misunderstood our corrupt intentions, we'll back out the change" apology
While I do hate Postman because its overcomplicated in everything.
But attitude like yours has shifted people and money away from developer tools. Instead of all the possible tools we could have from many developers, we are now totally dependent on big tech to sponsor it, like VSCode etc. And over time it would move in direction that will promote another service from the same company like copilot and vscode.
Developer Tool Developers are hurting themselves. I think it is reasonable to not want to have to log in to every darn thing you use on the internet. Especially developer tools.
Someone needs to invent a hat that developers have to wear: when the developer starts to write signup, login or authentication code, a hand pokes out of the hat and slaps him.
Default-on telemetry as well. I'm reminded of Balena Etcher phoning home with the names of ISO files you flash, which leaks the IPs etc. of which users are creating Tor/Tails bootable USBs: https://gitlab.tails.boum.org/tails/tails/-/issues/16381#not...
Yes, telemetry too! And automatic updates. They are all symptoms of companies’ obsession with having some kind of ongoing post-purchase “relationship” with their users. As a user, I don’t want this relationship! I just want to buy the tool and use it, without ever interacting with the manufacturer ever again.
If I buy a circular saw, I don’t want a relationship with Makita. I don’t want to have to log in to use it. I don’t want it telling Makita how many boards I cut and how well the saw is working. No offense, but I’m just not that into you, Manufacturer.
Judging by vscode's or copilot's or postman's popularity, login is not the issue. The issue is the quality of the tool and number of developers they can hire.
"A GUI for a command line tool" is, these days, at the level where you can get the first 80% of the value by asking ChatGPT to write it for you by copy-pasting in the bits of the man page for the options you want.
(The second and third 80%'s still need human intervention).
I also have fallen back to just using curl + jq and a set of saved commands since both postman and insomnia have decided to make my life harder not easer. good old plain unix command line tools never fails you.
You may consider giving httpie cli a test drive, if you are dealing with json endpoints. You can put in Bearer header and JSON arguments quite easily with
I know people don't love VS Code, but is there a reason Thunder Client isn't more popular? I know it's feature lacking compared to postman, but more so than curling?
It limits collections to 50 endpoints. I also couldn't immediately see how to plug tokens into variables.
Bruno is intuitive and has no pay-to-remove limits.
vim-rest-console[0] has been my Postman alternative for years. It basically wraps curl and makes it super easy to make different requests from a single text file. Can even write YAML and have it converted to JSON before being sent in the body. Really great tool
>How dare they try and run a business and get paid for their work
They can run whatever they want. I, and the parent, wont be using it.
Bruno has a paid option too, btw, and I'm fine with that. I'd be fine even if it was the only option. Login and extra BS features to tie me in? No, thanks.
Baloney. As other's have mentioned, Bruno also has a paid option.
Postman's problem is they took hundreds of millions of funding that somehow thinks an API request tool is worth $5.6 billion (though I'm sure that's waaaaaaaaaaaaaay down from the 2021 ZIRP frenzy). So now Postman has long since gone down the full enshittification path with a totally unnecessarily complicated UI and authentication and cloud features that hardly anybody really wants.
I like Bruno simply because I believe their approach is much better: simpler UI and, importantly, as their demo video points out, collections of API requests can be saved in an easy-to-understand format in git. Much better than some proprietary cloud storage.
You can't continue to make a product worse over time without expecting to lose some customers. When someone tells you why they stopped using your product, don't brush off the feedback as whiny entitled complaints.
Running a business is perfectly acceptable. Paid tools, likewise, as perfectly acceptable. Granted, most of software is built directly or indirectly on free work either of the intellectuals that discovered the foundational knowledge required to build it or of the engineers that built the tools.
What’s not acceptable is the rug-pull of presenting something as free and trying to claw back money from the endeavor after you’ve got users locked in. If you need money, don’t offer a free product. If you offer a free product, make sure you can afford it.
No one is going to judge you for charging the worth of your offering. However, you’re also not going to get free goodwill and advertising for no reason.
Spend your time and energy wisely, that is your personal responsibility.
I will usually take curl commands i end up calling a lot and use a function or script to make those calls easily. I find this to be way better for me personally. I feel using Postman teaches you only Postman. Whereas making shell tools and learning curl are so much more valuable. Plus, you can combine them with fzf, jq, fx, yq and friends to easily customize.
Shameless plug for Hurl [1]: it's a cli tool, based on plain text and curl to run and test HTTP requests. It's just libcurl + the possibility to chain and test response. You may like it! (I'm one of the maintainers)
I tend to collect little Ruby one or two liners for common REST calls, and now Go. Takes care of things like getting a JWT token and including it in the right header, as reusable code.
Takes slightly longer the first time than curl or Postman. But much more powerful in terms of using in scripts for operations tasks.
I'm tired of Postman freezing when sending JSONs over a MB in size. I had to purge it from the system a couple times because the tab wouldn't even load on start up making the whole thing unresponsive.
Postman dug its own grave after selling out itself for VC money. The “File over app” philosophy is a direction that we should be supporting after the Post-ZIRP VC money world.
I have nothing against this app or the other graphical HTTP tools like Postman, Insomnia, etc., as people clearly get value out of them, but personally, I've moved everything over to Hurl --> hurl.dev
- Open source
- Text files all the way down
- Easily understood DSL
- Easily distributed
- Easily versioned
- Fast
Download the executable, copy the two lines below into "first-test.hurl" and you're up and running.
GET http://localhost:3000
HTTP 200
I realize I'm fanboying a bit here, but Hurl really has been so helpful for our particular use case at wafris.org where we're trying to support a large number of different HTTP clients. We can just give an integration partner access to our hurl suite and they're good.
You reused a lot of "concepts" like captures, queries, filters, predicates etc... I take it as a compliment, there is a place for everybody (I'm one of the Hurl maintainers)
I did. And it is! The Hurl project definitely made Nap leaps and bounds better. Thank you for that. I wanted to take a different approach to how http tests are written (YAML, environments, parallelism, etc.), but for things that I already knew Hurl did very well (assertions especially, but also some other things like cookies) I pretty much followed the Hurl docs and reverse engineered them.
I tried Hurl after Insomnia went the way of Postman. The highlights you list were the strong drivers for testing it out. Where Hurl fell short was composing requests. Example: X.hurl response has authToken. Y.hurl uses authToken. Z.hurl uses authToken. There's no import ability[1], so you've got to use other tooling to copy X.hurl into Y.hurl and Z.hurl.
Ultimately settled on Bruno. It's backed by readable text files[2] as well. The CLI works for scripting. And the GUI is familiar enough that I've managed to convert Postman holdouts at my dayjob.
Can someone explain what Postman or Bruno is for? I know it's something for interacting with apis but why would i use it. I interact with apis a lot with curl or wrapper in my languages but never really needed something else?
Alot of people in tech/tech-adjacent cant use CLI, need an easier alternative. Also, instead of having a huge .txt/.md recursive directory of curl commands, programs like these bundle up request workflows into 'collections' etc..
Can be used to for api testing. Collections, token handling etc. Mostly for api testing, and collections can be shared among team members and source controlled.
For me it's more convenient than curl for three reasons mainly:
1. Easier to organize collections of requests in a visual hierarchy
2. Environments mean you can use the same collection to easily execute against local, dev, staging, production, etc.
3. Pre- and post-execution scripts mean you can programmatically extract values and chain into other requests (think grabbing an access token from an oauth request then using that token for an authenticated request)
It's basically just convenience features, nothing you can't get with other tools.
As someone who uses curl and postman regularly, both tools have their places: I've found curl most useful for quick ad-hoc requests, or if I need to figure out why my service is no longer working. Postman I've found most useful to create a library of requests that are available on-hand: If I need to call services but I don't want to have to remember what the exact URL is or what the exact payload is.
One more thing I don't see mentioned is that you can share requests with your team easily, so if you worked on an API integration, you can document it, share it with your team, and when the next time someone else needs to fix something, they can find something that worked at some point and has all the required fields.
Of course you could also just check in to version control these requests as curl commands, so if your team has the technical knowhow, that's about almost the same.
Or even better, you write some tests in your language to make these requests, then you have an integration test, too.
For me a big usecase is the ability to save specific requests and categorize / name them. It's a good way to document test data. If someone creates a feature which I want to test or debug I'd have to dig into the database to find which parameters I'd need to use, or I just find the right request in the tool.
To put it simply: Postman is for everything but what curl is for. Sure it also performs the actual request somewhere under the hood but that’s mostly irrelevant. Having a single integrated user interface (it could also be a text UI) to craft a request, sometimes sending JSON, sometimes a file, then sending it to inspect the result, then modifying the request then doing it again is very powerful. Not to mention OAuth/OIDC support and the like.
Sometimes, you have to find out how an API works, exactly. Sometimes you want to test your own APIs in ways the regular clients do not allow.
I had the same question. My current workflow in deploying a REST API is to write my own thin wrapper in Python and publish that so people can use it. I don’t know if postman/bruno saves me from having to write a wrapper. I also don’t understand the deal with “collections”. Maybe postman/bruno are good for creating a test suite ?
My use case (covered by postman but not Bruno) is to test a code base where unit testing is not available.
We have multiple environments with multiple parallel versions (think like dev/staging/prod and current/legacy), these deployments mostly have the same API with slightly different urls and credentials
We use multiple environments to easily switch between the various versions both for one-off operations (like a clear cache call that only needs to be called few times a year in response to external actions) and to manually test features.
I can see why not everybody would have this use case
Iirc Bruno does not have enough environment/variables/pre-post-request scripting support
Bruno/Postman is basically curl + a filesystem + git + jq + make.
If you're really comfortable with all those tools, you won't understand Postman because you'll say "why don't people just chain all these tools together?". It's like the famous hn comment on dropbox, "why don't people just use rsync"?
It's technically true, and if you're adept at those tools, you should probably use them instead of Postman. But yea, it's a useful product for a bigger set of people.
I found Bruno after Insomnia adopted the Postman strategy of being cloud first, with a disastrous migration - I momentarily lost all my local projects after an update.
I've been using it for a while and I really like the offline first + git collaboration aspect of it. Only missing Websockets functionality at the moment.
I would love to see more UI done in this style. That is to say treating your business logic as an API and then exposing it publicly to clients on different platforms.
443 comments
[ 4.5 ms ] story [ 432 ms ] threadLifetime license does not necessarily equal lifetime updates. 2 years of updates is generous enough for $19.
It seems like the API QA developer tooling has still room for disruption.
[0]: https://paw.cloud/
postman is really bad, nobody should use it. same goes for similar solutions, even this one.
Electron looks ugly, it doesn’t integrate, fails to handle HiDPI usually, in best case it eats a ridiculous amount of memory (factor 5x compared to native) and in worst case it has security issues due to Blink and lot of JS.
Electron is Flash for the Desktop.
It is exactly the opposite of flash.
Which I disagree with and provide my argument to show that any technical inconveniences parent poster noted, are not enough to say “Electron should be trashed and razed out”.
Discord the Electron app uses 1.2 GB of RAM.
Ripcord the compiled client uses about 30 MB of RAM.
That's a factor of over 42 times.
https://www.usebruno.com/about
Layoff happened, and we didn't yet have our postman software in our list of services to remove employees from. This is not Postman's fault.
One person had "deleted" all his collections and workspaces after the layoff to clear his laptop of all things related to our company. After we got an email from Postman saying our workspaces were deleted, I removed the laid off users. Since I removed the laid off user, the "trash bin" associated with them was also deleted. Postman support restored all the collections but the "environment" was gone. Which was all of our QA test keys, etc...
Our Postman collections are still in shambles after that, and we don't have any employees to manage it anymore. While I totally don't hold Postman accountable - there is definitely a reason why "no-cloud" is a good way to go with these kinds of tools.
Or perhaps write a script that has some kind of GUI.
Or maybe make the gui run the URL
You're right the possibilities are endless. And this Bruno and postman or permutations of that endlessness.
Also, using curl and the shell allows you to progressively iterate. So "write a script at that point" was kind of the point. Though you don't need to go that far to just feed authentication info.
GUI solutions don't have endless possibilities. You start and end with the exact same tool. The clicks and form fillings can't easily be copied around and iterated on unlike commands in a REPL. You can only perform tasks defined by the author of the application.
Also expecting end users to develop their own file syncing solution on top of FTP is unreasonable. Expecting software engineers to be able to use curl instead of a GUI form is not.
These tools are Mad Libs for curl commands presented as GUI forms. It does a subset of what curl + shell does while requiring more clicks. The target demographic are people who need to know the tool it's meant to replace in order to do their jobs effectively. That not easier or more convenient in my book.
Especially once a VC gets into the fold.
1. Open source everything, including the parts of the code that are currently premium
2. Switch to a copyleft license like the GPL
3. Start accepting substantial contributions from the community without a CLA
Then they'd be legally unable to do that kind of rug pull.
Happy to see Bruno at the top of HN
We will never take VC funding. We received around 10 inbound reach outs from VCs till date and have denied funding from all of them.
We will remain independent and I have written about it in detail here https://www.usebruno.com/blog/bootstrapping
They haven't.
Like, that's kinda the whole point of offline-first, local-only tools, you can 100% use them in a an environment you control and take responsibility for. Once you take control of customer's data, there's a whole litany of due diligence that must considered, and often at considerable cost.
Your link makes sense, and I believe you. Have struggled with similar issues. But who knows what the future will bring? Google once said "don't be evil"; Oracle bought Sun. Is there any way you can guarantee your future actions? Contracts, articles of association/company constitution? Maybe setup a trust or charity? I don't think there is.
Though Insomnia doesn't work with streaming responses at all, which is a bit of a non-starter in the age of AI. Anyone know a good streaming HTTP UI?
https://gist.github.com/CMCDragonkai/6bfade6431e9ffb7fe88
If not, is there an example of "streaming HTTP" you could provide that illustrates the limitation
Of all the http-client applications I tested (Curl, Postman, Insomnia, Bruno), somewhat hilariously Curl has the best support. It will output all 'Transfer-Encoding: chunked' with line-by-line buffering, whereas Postman only supports responses precisely following the `Content-Type: text/event-stream` format (strictly less powerful than curl, as this format requires newlines in between events, and a bunch of overhead on top of that). The others buffer the entire response before displaying anything.
The `Content-Type: text/event-stream` format is fine enough, but I personally prefer to just plainly chunk the responses and let the client choose whether to buffer them into memory and operate on the entire value at once, or interpret them live as the chunks come in. With tools like gjp-4-gpt (Gradual JSON Parser 4 GPT's) you can even interpret partial JSON objects live as they come in and display complex/nested data structures in a generative manner.
https://cr.yp.to/proto/netstrings.txt
Personally I use a lame but effective simple 85.9 KiB static binary filter, a small C program, that removes the chunk sizes so the response is ready for use by other programs, e.g., in a pipe. Buffer is set at 8 KiB.
Is there a way to experiment with one of these streaming JSON GPT APIs non-interactively by just sending an HTTP request, without need for a third party program, an account, use of a Javascript engine, etc.
I don't know a public API that returns JSON slowly, but you could simulate it by just taking a JSON string, splitting it into 3-5 char chunks, and sending each of those in a `Transfer-Encoding: Chunked` response at ~100ms intervals.
Actually, now that I look at the underlying mechanism behind `Transfer-Encoding: Chunked`, it looks like it's already basically the same as the netstrings. What I'm referring to is the (variable length) contents of the netstring/chunk being sequential slices of a JSON object.
Only for the flexibility to use more programs. Otherwise every program I use to process HTTP responses needs to be able to accomodate chunked transfer encoding. Plus only a minority of sites send chunked responses. Instead, have one program that does one thing: remove chunked transfer encoding.
IIUC, what you want is uniform chunk sizes where you know the size before you send the request.
GPTs sound annoying if they are so slow that they only output a few characters every ~100ms..
> IIUC, what you want is uniform chunk sizes where you know the size before you send the request.
I don't think so... I don't really want anything! Just a GUI that displays existing HTTP chunked responses as they come.
> GPTs sound annoying if they are so slow that they only output a few characters every ~100ms..
That's perhaps an exaggeration, but in general the speed and "smartness" of the model are inversely correlated.
Best of luck. Hope you can find the right program for viewing HTTP.
Not to mention, that bru syntax looks really nice.
Depending on which project I'm working on (and customer), I'll be using different tools to run em.
But to show you an easy example to follow, you could check out this jetbrains cli tool https://blog.jetbrains.com/idea/2022/12/http-client-cli-run-...
[1]: https://github.com/RESTEDClient/RESTED
But attitude like yours has shifted people and money away from developer tools. Instead of all the possible tools we could have from many developers, we are now totally dependent on big tech to sponsor it, like VSCode etc. And over time it would move in direction that will promote another service from the same company like copilot and vscode.
Someone needs to invent a hat that developers have to wear: when the developer starts to write signup, login or authentication code, a hand pokes out of the hat and slaps him.
If I buy a circular saw, I don’t want a relationship with Makita. I don’t want to have to log in to use it. I don’t want it telling Makita how many boards I cut and how well the saw is working. No offense, but I’m just not that into you, Manufacturer.
(The second and third 80%'s still need human intervention).
(Apparently it has a GUI version as well, but I'm not interested in trying it.)
You'll never guess who makes it.
How do you know it’s not a great experience?
0: https://github.com/diepm/vim-rest-console
I will likely buy Bruno because it is a one time fee and I control my data. It should work forever after that.
They can run whatever they want. I, and the parent, wont be using it.
Bruno has a paid option too, btw, and I'm fine with that. I'd be fine even if it was the only option. Login and extra BS features to tie me in? No, thanks.
Postman's problem is they took hundreds of millions of funding that somehow thinks an API request tool is worth $5.6 billion (though I'm sure that's waaaaaaaaaaaaaay down from the 2021 ZIRP frenzy). So now Postman has long since gone down the full enshittification path with a totally unnecessarily complicated UI and authentication and cloud features that hardly anybody really wants.
I like Bruno simply because I believe their approach is much better: simpler UI and, importantly, as their demo video points out, collections of API requests can be saved in an easy-to-understand format in git. Much better than some proprietary cloud storage.
What’s not acceptable is the rug-pull of presenting something as free and trying to claw back money from the endeavor after you’ve got users locked in. If you need money, don’t offer a free product. If you offer a free product, make sure you can afford it.
No one is going to judge you for charging the worth of your offering. However, you’re also not going to get free goodwill and advertising for no reason.
Spend your time and energy wisely, that is your personal responsibility.
[1]: https://hurl.dev
Takes slightly longer the first time than curl or Postman. But much more powerful in terms of using in scripts for operations tasks.
As it is the things I test start up faster than postman who is … I don’t know what it was doing when I quit on it.
I hope Bruno works better in that regard.
Postman dug its own grave after selling out itself for VC money. The “File over app” philosophy is a direction that we should be supporting after the Post-ZIRP VC money world.
1: https://stephango.com/file-over-app
It should also be easier to comply with GDPR’s Right to Data Portability (article 20) for applications that follow the “File over app” philosophy.
1: https://www.edpb.europa.eu/sme-data-protection-guide/respect...
- Open source
- Text files all the way down
- Easily understood DSL
- Easily distributed
- Easily versioned
- Fast
Download the executable, copy the two lines below into "first-test.hurl" and you're up and running.
I realize I'm fanboying a bit here, but Hurl really has been so helpful for our particular use case at wafris.org where we're trying to support a large number of different HTTP clients. We can just give an integration partner access to our hurl suite and they're good.IMO only thing missing for me is a predicate that checks every item in the array for some condition.
[0] https://naprun.dev
Ultimately settled on Bruno. It's backed by readable text files[2] as well. The CLI works for scripting. And the GUI is familiar enough that I've managed to convert Postman holdouts at my dayjob.
[1]: https://github.com/Orange-OpenSource/hurl/issues/1723
[2]: https://docs.usebruno.com/bru-language-samples.html
[1]: https://hurl.dev
1. Easier to organize collections of requests in a visual hierarchy
2. Environments mean you can use the same collection to easily execute against local, dev, staging, production, etc.
3. Pre- and post-execution scripts mean you can programmatically extract values and chain into other requests (think grabbing an access token from an oauth request then using that token for an authenticated request)
It's basically just convenience features, nothing you can't get with other tools.
Of course you could also just check in to version control these requests as curl commands, so if your team has the technical knowhow, that's about almost the same.
Or even better, you write some tests in your language to make these requests, then you have an integration test, too.
Sometimes, you have to find out how an API works, exactly. Sometimes you want to test your own APIs in ways the regular clients do not allow.
We have multiple environments with multiple parallel versions (think like dev/staging/prod and current/legacy), these deployments mostly have the same API with slightly different urls and credentials
We use multiple environments to easily switch between the various versions both for one-off operations (like a clear cache call that only needs to be called few times a year in response to external actions) and to manually test features.
I can see why not everybody would have this use case
Iirc Bruno does not have enough environment/variables/pre-post-request scripting support
If you're really comfortable with all those tools, you won't understand Postman because you'll say "why don't people just chain all these tools together?". It's like the famous hn comment on dropbox, "why don't people just use rsync"?
It's technically true, and if you're adept at those tools, you should probably use them instead of Postman. But yea, it's a useful product for a bigger set of people.
Any idea if the CLI app is available as a standalone? Looks like its a "desktop app + cli” or nothing deal from what I can find.
I've been using it for a while and I really like the offline first + git collaboration aspect of it. Only missing Websockets functionality at the moment.
https://github.com/pashky/restclient.el
It does just about everything you can think of, and since it’s just “a text file”, easy to store in git.
The ability to easily use the output from previous responses in subsequent requests makes for great story demos and/or test cases.
And it’s all done in VS Code, using tools/keystrokes/colors you already know and love. :)