History goes in circles. New API client appears, adds features, userbase grows. Forced login is added, users are angry and look for alternative. New API client appears...
[deleted]
Bruno: Fast and Git-friendly open-source API client (Postman alternative)
281–290 of 444 posts
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#282Switched from Insomnia around one year ago! Really like Bruno :)
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#283Can someone help me understand the difference between the .bru file and an OpenAPI spec (Swagger), aren't they representing the same thing with different syntax?
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#284Why not the .http files that IntelliJ and VSCode have implemented for years now?
This should've become the standard by now.
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#285It may already be the case but it's not clear. If Bruno supported importing Postman collections it would be an easy decision moving across
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#286Good to see some more open source competition in this space. SoapUI had most of those features some 15 years ago. I never understood why Postman became so popular, my current team even throws money at them.
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#287I find interesting on how on a startup related forum, anything related with not paying is always celebrated.
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#288Good to see some more open source competition in this space. SoapUI had most of those features some 15 years ago. I never understood why Postman became so popular, my current team even throws money at them.
Basically because of "blah but it is Java!" kind of argument.
SoapUI is great.
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#289Earlier quoted context omitted.
"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,…
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 chun…
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.
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#290Can 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?
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.