If you are looking for an alternative to Postman take a look at Bruno.
Bruno does basically the same thing as Postman, but the app is offline-only meaning all your API Requests are stored in config files on your computer. That makes it for example very easy to share whole collections of API-requests on Github.
Plus you don't need an account and the app is open source.
Yesterday, we played with Llama 3 using the Ollama CLI client (or REPL). Today I figured that we would play with it using the Ollama API. The Ollama API is documented on their Github repo. Ollama has a client that runs when you run ollama run llama3 and a service that can be accessed from something like MindMac, Amallo, or Enchanted. The service is what starts when you run ollama serve.
In our first Llama 3 post, we asked the model for “a comma-delimited list of cities in Wisconsin with a population over 100,000 people”. Using Postman and the completion API endpoint, you can ask the same thing.
You will notice the stream parameter is set to false in the body. If the value is false, the response will be returned as a single response object, rather than a stream of objects. If you are using the API with a web application, you will want to ask the model for the answer as JSON and you will probably want to provide an example of how you want the answer formatted.
Dear lazyweb, I struggle with Postman for testing APIs (for various reasons, not least the cloud bias) and see that there are a huge range of newer alternatives, any suggestions for a simple, straightforward, non-cloud app for testing REST APIs? #postman#rest#api
Bruno is a Fast and Git-Friendly Opensource API client, aimed at revolutionizing the status quo represented by Postman, Insomnia and similar tools out there. https://www.usebruno.com/
@voltagexscreaming internally it seems to share big part with "GUI is always easier and more convenient attitude".
I had to test #Postman collections written by someone else. First I tried wit #Newman. Typed command, options, these are variables, these are data files... Cool, everything worked as intended.
For debugging minor issue difficult to catch I thought I should try with real Postman later. Constant errors, some variable not accessible, bad requests, something burried in some menu not set... (All when actively avoiding creating their stupid cloud account)
Why the hell most people say GUI is the best option?! :blobcat_sobbing:
Last May, the populare API tool Postman pivoted to be a cloud-only product for many of its features. This might have a serious security impact as developers often store high privileged access tokens there, in some cases they might even be exposed through the Postman API search features.
We did a quick check for some of our customers and already discovered some valid tokens.
Check out @Lee_Holmes blog post on this. Also kudos to @wdormann for pointing this out first (at leat to our knowledge).
I opened #Postman today and my collections and stuff were nowhere to be found and a message saying don't worry, just login into yada yada. Excuse me but I thought I had a local app to do local development? Ah OK, a short 'net search later came with an Insomnia fork (which, BTW, apparently came into play when those did the same move Postman is doing now), and hey, an Appimage ready to use, so hello, #Insomnium. It's FOSS, works great, no logins. Now that I'm here: thanks to their devs. :)
In #Postman I had this settings to request a new OAuth 2.0 token to my API and automatically use it in every API call. How do I get the same with Bruno?
What is up with them forcing people to push their information to their servers through the Scratchpad deprecation? This seems totally uncalled for to not support a local development option and require synchronization to external storage.
This may have been around for awhile, but I just found that Postman has an AI code generator that can assist with making visualizations of API responses, including Mastodon search results.
Roughly 2 weeks ago Google patched a critical vulnerability, CVE-2023-4863, that was being exploited in the wild. The broad impact of the root cause of the vuln and the fact that it will have a long tail of unpatched software has been poorly communicated. You can read more in @dangoodin 's excellent article on Ars Technica.
As pointed out in the article above, Electron is based on Chromium and is impacted. Electron is bundled in a ton of apps that people might overlook.
I threw together the following shell command to help macOS audit which versions of Electron apps are installed.
find /Applications -type f -name "*Electron Framework*" -exec <br></br> sh -c "echo "{}" && strings "{}" | grep '^Chrome/[0-9.]* Electron/[0-9]' | head -n1 && echo " ;<br></br>
When run, you should see something similar to the following:
/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework<br></br>Chrome/114.0.5735.289 Electron/25.8.1<br></br><br></br>/Applications/Slack.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework<br></br>Chrome/116.0.5845.188 Electron/26.2.1<br></br>
How do I run a simple, comprehensible #Mastodon instance? I'm not crazy about setting up and installing the usual server. I have simple needs and want to experiment with my own instance.
It would be great if such were written in #Rust. But I can hold my nose and use a different modern compiled language.
I do know how to search the web. I do! But it's easy accidentally to waste time on something hopeless.
I'll happily be the only user and tolerate jankiness.