Why are all of the API clients so intent on storing all your requests and environment config in the cloud?
We would keep a directory of relevant collections and environments inside all our application repos, so they would simply be committed along with the code, be versioned, included in PR reviews, etc. But it looks like all of the popular REST client tools use some hidden cloud services. This is also terrible from a security perspective, since environment variables are likely to include secrets.
And it causes a completely unnecessary versioning problem since the API client code lives separately and not even in a repo typically.
There’s a VSCode extension that executes REST and GraphQL queries stored in a plain text file. So much simpler and more secure. I forget the name - maybe REST client?
Kreya[1] does exactly that. It stores all it‘s data in easy diffable text formats in the filesystem. Currently kreya is limited to gRPC. However, REST support should land soon.
It's easier to monetize that way. They manage the convenience, your team pays them money. Once your team is using it, you're soft-locked in to continue using it.
Yes, agreed on the security perspective. It's not a secure tool. For that you should consider a desktop client (eg Fiddler) rather than a browser based client
I've used both Postman and Insomnia, but recently I've been using the REST Client plugin (https://marketplace.visualstudio.com/items?itemName=humao.re...). It's not a feature-rich, but I honestly like the workflow of not having to switch apps and work with files in my editor (as well as put variables in a .env)
It's been my favorite for a while as well. I like the simplicity and the ease that you can figure out what's going on. I don't need the ability to save libraries and sophisticated variable sets; that just makes the UI cluttered and confusing (like PostMan.)
I'll give it a go, looks promising! I have had a great time with Insomnia (insomnia.rest) and pretty much anyone I recommended it to ended up sticking with it. Postman has became way too bloated, it's amazing to see how there's always room for new and slimmer approaches.
Wow, I love it. Postman and Insomnia disappointed me, it became a mess and push towards sync makes it a bit dangerous to use. Thunderclient seems like something to really fill my that void.
My main grouse with these REST GUI clients is how much memory they consume. Maybe because they are electron apps in the end, but it's just funny that nobody's devoting any time to create native apps anymore for something that should be a utility and not the main app.
I haven’t used Paw because I have very little need for a tool in this category lately, but I’m tempted to buy it anyway just to reward them for developing a good native Mac UI, and not restricting it to a subscription model.
I'm working on something a bit orthogonal, but similar in spirit: a “network requests” tool, similar to the Network tab in Devtools, but batteries included and working _both_ as a browser extension and a reverse proxy standalone app – so you just pick whatever suites your workflow better today. It's still super early stage though.
I've been using https://insomnia.rest/ and I am a massive fan. From the ability to make dependent API calls to say log in with one API call, and inject login tokens into the other from the first's response is amazing!
Overall this tool has been my go-to for 3 years now.
I wrote https://github.com/lnenad/probster using GTK3 so it can be used on weak machines, top ram usage was 40MBs in my experience. It's pretty barebones though.
Is there a command line tool or editor plugin where I don't have to specify parameters, learn all the options. Instead I would just point it to an "http file" with http syntax and it "runs" it. Meaning the file contents are the http request that I want to send, eg
And the I can just run it like so `http myRequest.http`
There are some decade old sublime text plugins that claim to do this, but none of them seem to work anymore, from what I'm seeing.
From a CLI you run into issues with `nc` and the like supporting https. You can get close with `curl` since it has a -H option that allows you to provide headers in a file.
curl -v -H @request1.txt neverssl.com
With a request1.txt header file
X-Header: mine
User-Agent: bob
Will generate a request of
> GET / HTTP/1.1
> Host: neverssl.com
> Accept: */*
> X-Header: mine
> User-Agent: bob
You end up needing to know 3 options. -X <METHOD> to specify the HTTP method, -d @<file> if you want to send a request body, and -H.
Will you add an Electron version? A browser-based HTTP client is nearly useless for me because of CORS. I couldn't come up with any interesting internal endpoints to even test this with. I thought "Install app" was going to give me an Electron version, but it isn't; it's still the same thing with the same restrictions.
Had a similar issue. You have to use their browser extension: https://chrome.google.com/webstore/detail/hoppscotch-browser.... Click on this extension and add the domain you want to query. Then on Hoppscotch, go to settings and click "use browser extension to send requests."
I was using Altair's desktop app to handle CORS, but may switch to this set-up.
If I create a team and share requests, do I also share passwords and other credentials? If so, where are they stored and how secure is that?
I work for a company with many different project. Is there a workflow where I can save a workspace as one file and save/load it with my project from Git (or any local folder on my computer)?
If you create a feature to host a Docs page in the future, please improve on Postman's.
Theirs lacks key features and introduces bad ones:
1. Locks you into their Collections datamodel. Results in the API being maintained outside OpenAPI generated files because your annotations can't be easily merged with new endpoints.
2. Unable to password protect the API docs, even with a basic password.
3. Unless this changed recently, there is no way to re-order the endpoints or the responses without manually removing and re-adding them! Absurd.
Hey! So I tried to import a Postman collection, but the pre-request scripts aren't getting imported. Neither are the sample code snippets. Is this not implemented yet, or is it a problem with the collection (or something I'm doing).
i'm really really curious - how did Hoppscotch get so many github stars? sorry if this is superficial but you've reached a level of stardom very few projects reach and in seemingly very short time.
Not a question, but a complaint. Your machine translated interface falls short of being acceptable. Either give the l10n job to a human, or don't do it at all.
The Swedish translation. I had to switch to English to figure out what some buttons did. For example one of the buttons at the button show "Jaktplan" (fighter plane).
Also there are a lot of extra spaces inserted in words with dashes or colons in them and some strings are simply not translated at all.
Danke. Fixing typos and other small grammatical problems in open source projects can be a good, easy way for people to get started; so my hope is that by sharing a few of those, you've created the opportunity for someone (maybe me, maybe another observer here) to contribute an improvement to the project. It's also an attempt to maximize the value of your complaint.
I am calm. I am not talking down. Examine why you made bad assumptions, and could not see my post for what it is: sharing a hack to improve one's life.
I'm not GP, but your replies in this thread read as arrogant. If you're getting called out by multiple people, it is probably not them — and sure, you may have good intentions, but they are not coming across as you think.
Hoppscotch raised money right? Unfortunately the nature of most VC backed companies is to believe features are the answer to monetization and enterprise adoption. These things quickly become bloated because of that. So people slamming Postman, yes the product has become a Swiss army knife, but they're trying to figure out how to scale a business long term and that often means leaving behind free users. Don't be surprised if hoppscotch does the same.
A bloated mess of a tool is going to get dropped by developers. The last thing we need is a something like postman hamming up our day.
Logging in, online this, cloud that. No thanks. The end for me was when it took me a half hour of failed google searches to import an old collection. They are going to lose enterprise inertia, it has already started.
One time I downloaded hopscotch, and it was sending network requests to download an asset (css file) on every keystroke. I'll never use it again. Ever.
I tried very hard to convince the hoppscotch devs to adapt something like .http files so they could be stored in version control. Only a few tools get that right.
Sadly I don't think they never understood the actual goal of it. And just added github to sync to or something like that. Which isn't what I was looking for.
I use IntellIJ and the http client does it and it works very well. But sadly the rest of the http client is annoying just basic stuff like reading the response is always a few more clicks than I want and compared to Insomnia so much harder.
I'm not the parent poster. Your question assumes that Postman / curl / anything are used to test something. I generally use those kind of tools to explore an API and I write tests later if I use it or never if the team decides to use something else. After all a project defines very few APIs but consumes a lot of them from external entities, at least in the projects I'm working on.
I suggest you could try Hurl (https://hurl.dev). It’s a cli tool to send and test HTTP requests, in plain text.
As I’m one of the maintainer, I find it quite readable…
> I want something much simpler, so I use VS code with a "REST Client" plugin
I follow the same approach. Emacs, Verb[0] and org-mode. An alternative to Verb would be restclient.el[1] but I like Verb more because it works as an extension to org-mode which is great for documentation.
This is the way; if anything, your requests are in plain text in your version control right next to your code, instead of in a proprietary format or intentionally hidden away in a cloud service (postman).
Postman collections are just JSON, but that JSON is impenetrable to humans and merging algorithms. Rest client shows how a good file format can be a huge advantage.
As a small dev team we have a workflow to rapidly author tests integrating our internal and external graphql + rest APIs.
These tests can be run, tweaked and parameterized in various environments from the GUI, and then imported into our CI system with Newman. Its a low code approach that's saving us time so I'm grateful of the features we are getting (for free) with Postman.
Would you not be better off making those tests in your programming language of choice, which is likely the same as the code under test, be it Python, Node.js with Mocha, Ruby, Java or C# ?
Or even avoid programming languages as much as possible. Most of my API tests are done with curl and jq. (Which I blogged about here: https://lambic.ca/blog/api-testing-with-curl/)
I think you're actually testing with bash (and included tools) there.
Which is fine, bash is a programming language of sorts (I see "if" statements!), and you can store the tests in text files in git. If those are the tools that you like to use, and it works, great.
That's why I said "as much as possible". I keep the bash scripts as linear as possible so they are "scripts" rather than "programs".
We started out using cypress, which I was convinced was the wrong tool for testing APIs so I switched to this approach, which sped up our CI deployments significantly.
Yeah, I have been using httpie (which offers a better DX) in similar fashion.
It also pairs well with (n)vim - I can just run :.!http whatever and have the response injected into a vim buffer where I can inspect or slice and dice the json with my usual vim workflow.
For testing an API layer, whose different API microservice implementations might be in different languages, and/or in languages your API test automation team don't understand, then that probably wouldn't work well. Why do you think it would?
I meant to say, what is the case for Newman over "pick a programming language that you like and know, and write the http tests in that" ?
It was my assumption that the people writing the APIs were also writing the tests, so they would prefer the familiar language.
If you have "different languages" in play, you get to choose one of them for tests. I've seen it happen that a language is chosen for test that is not in use in the API's at all. It's only "likely" the same language, as I said above.
If you have a isolated "API test automation team" then it sucks to be you, but the language choice would be on them, wouldn't it? I don't think that I implied otherwise.
> If you have a isolated "API test automation team" then it sucks to be you, but the language choice would be on them, wouldn't it? I don't think that I implied otherwise.
You said the tests should be in the implementing languages
On the "sucks to be you" - I have test automation folk in the team delivering software alongside everyone else as a cross-functional team; I just used the word "team" loosely to mean "the group of people whose job it is to do certain levels of test automation".
> It was my assumption that the people writing the APIs were also writing the tests, so they would prefer the familiar language.
The point I'm making is makes sense for unit tests, semi-unit tests, and possibly also for lower-level API tests (e.g. API testing an individual service), but when you have to test functionality across services, you might well not want to pick a technology that the service(s) under test were built in.
> You said the tests should be in the implementing languages
No, I did not say "should", I said that they would "likely" be in the same language, for reasons given above. Yes, I get that there are also reasons to deliberately choose otherwise.
> but when you have to test functionality across services, you might well not want to pick a technology that the service(s) under test were built in.
Great. For the third time, what is the case for Newman being that technology, over a well-known programming language?
For me it's because people already know and are already using Postman. We already author collections for services that other devs in the company reference when using our APIs.
Sure we could write the tests in python or whatever, but everyone is already using and likes Postman for the most part. And replacing the postman collections that people use for reference with a folder of scripts I don't see going over well.
I'd personally prefer something like https://hurl.dev where you have a readable file in source control, but that's not a battle I'd win at this point.
Yeah it's turning it into a tool not for developers, or for very poor developers afraid of code.
There might be a market though for people "building APIs" through no code/low code tools like zapier and ifttt. Then I suppose they can sorta test their low code contraptions with this without knowing much about coding.
IDK if I am a "poor dev" but I find the Postman interface extremely complex and confusing. There are tabs, dropdowns, logins, collections, modes etc. Getting it to work is a chore.
A http request written entirely in a text file is IHMO far clearer.
The syntax of this plugin seems very similar to dot-http[0] and IntelliJ's REST client. Super interesting. Would be really interesting to have these three fully compatible with each other.
I got access to this today. They basically started to recreate Hoppscotch (https://httpie.io/app) and then packaged it as an electron app. Hoppscotch has a lot more features though.
Paw is _beautiful_ but it has no GraphQL tooling at all, I think? (Just native POST requests etc.)
(Unless there's a beta you're using?)
I use Insomnia but I am quite keen to start building myself a local-cloud-based toolset so I can reduce my reliance on a single machine, so Hoppscotch looks interesting.
Hoppscotch and other gQL clients allow introspection on the GraphQL schema so you get a API reference out-of-the-box. Makes it super easy to write queries and mutations.
Maybe I never appreciated the power of Postman but I never understood why they thought it would be a good idea to charge monthly for a tool that's just a gui on top of curl (or Invoke-WebRequest for those of a Windows persuasion).
Sorry, but with that attitude, why use curl, and not just netcat or socat? Or just write bash scripts manipulating sockets directly?
I think you underestimate a bit what postman can do. Just a few things: import openapi specs and do pretty complex requests with a few mouse-clicks, supports various auth mechanisms (oauth/jwt/...), allows for some scripting, run mock versions of an API spec, generate request code for various languages and frameworks, and yes, copy a request you created with point&click as a cli curl command.
On top of that, you can easily save and share this in teams.
Yes, people would just script netstat. I mean the argument is getting ridiculous, as another sibling points out, cURL would be nowhere today if it wasn't FOSS.
Its not obvious that CURL would be as popular as it is if it started with a pay to use model. Maybe it never got the attention it has and never got popular?
If you use a tool whose state is stored in text files, then git solves the "sharing among teams" issue for free. So it's a paid solution to an invented limitation.
To preface this, I'm not a massive fan of postman. I find the user experience to be counter intuitive compared to the likes of insomnia. With that said we use it pretty heavily so I might be able to provide some insights.
This is kind of expanding on koeffiezets comment.
For me postman's 'value add' can be broken down into three areas.
Technical Capability:
- UI alternative to curl
This is the most basic usage and a lot of the of other functionality is extensions of this. For simple get/post requests, this is definitely the case. I wouldn't trivialise it though. For folk not familiar with curl there's a lot of gotchas when it comes to escaping, handling auth, etc. I'd say that the UI on top of curl is more accurately viewed as an alternative to things like jetbrains's build in http client.
- The ability to import openapi/swagger/protobuf (as of recently) and generate collections
This will be the most commonly pointed at benefit of postman (and others like it) in my opinion. It's a pretty solid one, especially if you integrate with the API during your build process to version/upload the API specs.
This combined the the 'UI alternative to curl' really gives a lot of the foundational power for the other postman features. Even as openapi/swagger docs on steroids with a richer http client this gets pretty powerful. Especially with the sharing capabilities which I'll touch on under the team side of things. As with a lot of this stuff, you /can/ do this without postman. You could use the openapi client generator to produce a curl command.
- Auth handling
So postman has pretty rich support for a few auth types (api key, no auth, oauth 1.0 & 2.0, signatures, ntlm etc). This I think is where some of the power of postman really begins to shine (and tools like it). Handling auth in curl can be a real pain. Creating a way of handling auth which can be shared across a team becomes even more of a pain, especially if we're talking about auto refresh and the like. At this point you're really in the realm of writing small-medium custom scripts to wrap the auth handling, save the tokens, refresh.
Having a standardized way of handling this with the ability to extend it if needed can become a massive time-saver.
- Mock Servers
There's a bunch of ways to do mock servers and I wouldn't say postman is technically the best ( personal preference is stuff like wiremock). With that said, sometimes 'technically the best' looses out to what's immediately available. Having it built into the system which already has your open api specs, has SWE familiarity and is already there will often make this win out. It can also get folk thinking a bit more about their mocks/contracts than they would be otherwise because it's just part of the existing toolchain.
You could technically do this with netcat, or using a language specific approach, or another tool like wiremock. The first is going to be a pain to maintain, the second doesn't work great for multi-language environments and while wiremock and it's ilk are easy to get up and running with, they do require additional setup and management.
- Postman echo
Kind of an alternative to the like of pipewire or running your own nc/other implementation. Simple concept, simple implementation, but having the ability to create an endpoint to post/etc data to, see what the output looks like and run it in a place which other engineers can access and you can collaborate easily on the output is a nice to have. Basically saving on the setup time/individual contributor trying to collaborate side of things.
- Newman
This loops back to curl. A CLI tool for running postman collections. I'm giving it a special callout because if it wasn't for newman I'd have a lot more reservations about using postman. With newman, being able to take collections/imports from the UI and then use them with newman to do things like helm chart tests/continuous testing/run easily in a container allows the effort invested into creating stuff in postman and extend it beyond just the local dev experience.
- Other
There's also a whole bit around the API workflow/editor that I'm not going to touch on as I dont know that side of it well enough, but, it is there and something to be aware off.
'Team' Capability:
With everything above, it's important to remember all of this can be done in a shared collaborative environment with a full audit trail and potentially SSO depending on the tier. Removing all the friction from that is a pretty big deal (especially as companies grow).
The point about using a text based standard is valid (one of the things I like with jetbrains http client is this). But managing that for all the functionality of postman would be a challenge and bits would be likely to rot.
Just having a tool which does most of it well enough can be enough as it reduces friction.
Another point on this is cross os teams. We have a mix of linux/windows/osx users. Curl is great, and does work reasonably well on windows, but trying to maintain scripts/bespoke implementations/knowledge across folk on all these platform is a losing battle.
Integrations:
Kind of a final and often overlooked note, but there's also a rich integration system with postman. Stuff like integration with new relic/data dog/etc to record test results gives one example but it's a pretty solid ecosystem.
Closing thoughts ?
That was a ramble. To summarise:
- Postman is definitely bloated, but that bloat/bredth of functionality can be useful
- You can do everything postman does without postman, but depending on the team size/number of services/etc there's value in having a standardized, cross-os and easy to share solution.
If I was just doing stuff as an individual contributor or had a single team ? I wouldn't necessarily go with it. For larger orgs or as you go from startup-scale up there are definitely advantages in having a master of none tool to help adoption. Regardless of if it's postman, insomnia or hopscotch I think reducing it to curl with a UI is leaving a lot on the table.
Makes two of us. Maybe, if you're working on a really large project? But then there should be time and money to set up a central tool for mockup and testing.
If, like me, you have strictly no clue what this is for and still don't after navigating both the site and the github for 10mn (Hoppscotch is a community-driven open source API development ecosystem ... ??????), here's an insomnia vid that sort of starts to clear the fog:
I thought the title is fine as is, because this project is only interesting for those who know what Postman is, which is kind of the industry standard in its field. Long story short, both of these are tools used for testing APIs. You use them to test an API call using different settings, and monitoring the response. They have more advanced features of course, but this is the main use case.
I've personally moved to Talend. Talend is browser based and capable of using existing auth cookies. It's a game changer if you have to work in an integrated environment where it's not possible to run those auth services locally.
When I started using Talend this was not possible in Postman or others. Curious if that's changed.
Nowadays I am quite satisfied with the RESTer firefox addon: https://github.com/frigus02/RESTer. This does look neat but there is no explanation on how to install it locally, and telemetry is enabled by default.
Insomnia has not been a drop in replacement for me, but its "request chains" are fantastic. At this point it helps put up with its different set of problems.
IMO, Insomnia has been bloating up to the point of ruin just like Postman did. I've moved from Postman -> Insomnia -> HTTPie beta GUI. The number of clicks between a new Insomnia installation and typing in the URL for your first request is absurd.
I just tried HTTPie beta GUI. For an app that is basically a wrapper of their CLI, not sure why I would need an account and join a waitlist. No thanks.
I have been using Insomnia for a few years now but was blown away when a colleague told me i could right click the send button and get some additional features... Crazy UI anti pattern. There is no hint that this button has a secondary functionality.
Very similar experience for me too - once Postman starting nagging about enterprise-y stuff/account creation etc, I switched to Insomnia and I really enjoy using it. Beyond the typical REST/graphQL support, it has the ease-of-use features like environments/grouping via directory structure/variables etc while not requiring any sign-up, allowing local export/import without having to go through cloud etc.
The only concern I had was lack of support for multiple tabs (which Postman allows) but having used it for a while, I don't find this to be an issue anymore; infact, I like that I no longer have to tab hunt like I used to in Postman with scores of open tabs building up over time.
I've also been using it (an older version Insomnia REST), but recently I tried to upgrade to a newer version and it's unusably slow and has graphics bugs for some reason.
I wanted to try Insomnia, but could not install their deb package on my Debian: it depended on a "libappindicator3-1" which is not available in my current release. I'll stick to basic CLI tools when I experiment with web APIs.
The Swagger editor doesn't support OpenAPI 3.1 either, which is surprising since the OpenAPI spec was initially ported from the Swagger format.
I raised an issue for this a while ago. Insomnia uses the Swagger UI library, which also (bizarrely) doesn't support 3.1, so Insomnia is blocked until that library is updated.
Love hoppscotch! Moved to it from postman back in the postwoman days. They really cleaned up the UI recently, made saving and sharing collections super easy.
And there's a chrome extension so you can proxy requests through your localhost to avoid CORS issues, etc.
Interesting that they replaced the product name "Hoppscotch" with "Hüpfburg" in German. Not sure what's the reason, as it's not even a correct translation. German also seems to be the only language the devs did that.
I noticed that, too. Especially since the tool even presents itself as Hüpfburg instead of Hoppscotch. But it's nice you are able to change the language in the settings of the tool itself instead of having to tinker with your browser's language or even user agent/request headers.
i have to ask here since this is about api. i have a use case whereby i have to do some sort of "one time password" processing via email. the otp gets on the email. that email is forwarded to a "server" which regexes the body and outputs the OTP and some other fields like email address forward.
at the same time, the user would be using a browser extension and once that detects the user has requested OTP, a request would go to the "Server" which would match the two requests and send the browser extension the necessary OTPs.
i know the whole privacy thing around it, this is a small project and the OTPs themselves arent tied to any banking and stuff, just office work..
then there is another thing about captcha proxy using those captcha services. i do not want users to directly access the captcha api key, they should use internal keys for accounting purpose.
i have found "fusio" on github but it is terrible at explaining how to proceed and the documentation isnt that great
if you use gmail you can write appscript to extract the otp(regex part), service that sent the otp and timestamp when you recieved the mail to your "server" via post request.(i am assuming you know how to make a post request with dummy data using curl or javascript)
you can use django/ruby on rails or golang for your server, authentication is available out of the box for django and there is great documentation for api.
I am not clear on what you intend to do with captcha so no comments.
i plan to use a mail server independent of google so i can manage more parts of it without being subject to limitations of the email providers and because i am not going to "send" any email, there isnt even a problem of deliverability.
my question is that does there an appscript alternative that i can self host on my server..
there are three parts to your problem
1. recieving mail and processing it. Since you are planning to host it by yourself answer would depend on what are you using for hosting. Solution can be as simple as reading a file(i.e. recieved mail) and extracting relevant fields using whatever language you know python/shell ecript etc. This part would be highly specific to what you use as your mail server.
2. server that responds to the api request made by chrome extension. This is where you can use django it would provide basic security as well as cater to the api request made by your extension here any server would do as your use case is quite simplistic. It should be few lines of code depending on your familiarity of language.
3. Chrome extension this would be in javascript.
are you developer? or do you have access to developers? if yes than it should be straightforward.
That's one of the things the .io domain hints at, along with the completely blank page when loading the website without JS enabled, the myriad of NPM dependencies and the fact that it is advertised as a lightweight tool while being a Vue SPA that loads 13 M of minified JS code (that's if you block google trackers), and google trackers.
I often use the RESTED firefox extension, which covers like 90% of my adhoc http request needs: https://github.com/RESTEDClient/RESTED
It's pretty slim with no bells and whistles.
I use cURL a ton too, for when I want to make a one-off request, examine the response, and then throw it away. Here are some reasons why I'd reach for a tool like this:
• I want the history of every request and response to be saved by default, so if I ever need to look back to one I know it's available
• I'm sending several similar requests and I want them to share a set of variables, or, I want something in the response of one request to be used as a parameter when sending another
• I want to set a URL parameter with a bunch of symbols in without worrying about quoting
• I have so many types of requests that I'd like to organise them in a tree
• The JSON returned in a response is absolutely massive and I'd like to expand/collapse subtrees instead of viewing the whole thing as unhighlighted text
>• I want the history of every request and response to be saved by default, so if I ever need to look back to one I know it's available
Requests are saved in .bash_history and easily greped from the command line. With fzf, it's addictively good. Responses are not saved, but it's not something I miss, but it could just be a lack of habit of mine.
>• I'm sending several similar requests and I want them to share a set of variables, or, I want something in the response of one request to be used as a parameter when sending another
Again, bash, a bit of scripting for me goes a long way.
>• I want to set a URL parameter with a bunch of symbols in without worrying about quoting
That's a good one. I usually end up resorting to a real programing language like PHP or Python when I begin having to scape special characters much
>• I have so many types of requests that I'd like to organize them in a tree
Haven't felt the need, again, could be lack of habit.
>• The JSON returned in a response is absolutely massive and I'd like to expand/collapse subtrees instead of viewing the whole thing as unhighlighted text
Same here. Curl, bash, jq, etc. But of course not everybody is comfortable on the command line. I notice a lot of frontend developer seem less familiar with that stuff, for example. Non technical people are typically also not comfortable with UI based tools for this.
The exception for me is stuff like graphql. It's nice to have some code completion for that since it is so fiddly and verbose. Likewise, I use Elastic's dev console to interact with Elasticsearch/opensearch.
Otherwise, I avoid doing a lot of manual requests to anything. Most of my systems end up having some kind of admin UI. I don't want people faffing about with curl commands to do routine stuff and then messing it up and creating a mess. That just doesn't scale. Building a UI usually implies building a good api client. I've also scripted together a simple cli in the past with just curl and some bash commands. A bit more work but nice once you have it. The downside of cli is that only techies can use it. Having a ui means you can hand off responsibility to less technical people or customer support. So that actually reduces my workload. Postman, SoapUI, and whatnot are too low level for that. And once you have a decent API client, you can also use it to write good tests that don't just copy/paste a lot of http stuff around.
I once had a test engineer that insisted on writing tests using SoapUI (which as the name indicates was originally intended for testing SOAP stuff but eventually evolved to do REST stuff). Big PITA to deal with these tests because they were highly flaky and he just copy pasted shit around in SoapUI so it took ages to fix anything. Also asserting anything useful was also a bit limited. Basically any trivial change you made to the code, dozens of those tests would fail. The more tests he added, the worse it got. We eventually replaced those tests with a proper API client and integration tests that we could actually refactor in a sane way and run concurrently. The result more, better, and faster tests.
There are already many tools for many things in the Linux base userland, installed per default. Mankind could save many CPU cycles and developer days if we'd be able to read the existing documentation and learn to use them.
But instead we are here, people are baffled if projects run on bare Debian with no extra dependencies as if it was some kind of magic.
It's easier to do the OpenID authentication dance with a tool vs curl (especially when doing PKCE requests), and I use Postman to build up some documentation for my APIs.
Interesting to see that the website clearly makes it look like the app is open source, the very first thing on the page says "View on GitHub". But only upon visiting do you realize that the repository is just for bug tracking purposes.
I can't find it either, which is why I said they should have linked it. In Microsoft Store, you'll see Free+, meaning the base version of this app is free, but there are in-app purchases.
Agree, after researching this a little while ago, those are the two best alternatives. Was bit by HTTPie not supporting HTTP2, but both of those do. xh (Rust) is also faster (yes, in practice, try some large responses) than HTTPie (Python).
Edit: also just want to say, in a world where "the current GUI tool du-jour got bloated and this one has hidden behavior when you right click this button...", I much prefer command line tools where possible!
Last time I looked at Postman and Insomnia, the exported xml files were not compatible with each other. I hope we end up with data portability at some point.
It’s impressive that there’s a clear effort to make the UI usable on mobile. A very rare thing for developer tools which aren’t specifically mobile oriented.
The website linked is not a landing page, but the actual tool, which is based purely on JS (Vue and Typescript to be precise). Here is the Github repo:
We would keep a directory of relevant collections and environments inside all our application repos, so they would simply be committed along with the code, be versioned, included in PR reviews, etc. But it looks like all of the popular REST client tools use some hidden cloud services. This is also terrible from a security perspective, since environment variables are likely to include secrets.