We built this because current API tools don’t deal with the fact that some APIs are just painful to work with. For us, it’s usually error after error as we try to figure out how to properly form the first request.
We recorded a demo to show you how TypeScript helps us autocomplete a request correctly. https://youtu.be/O_Mly_p-g5s
How does our platform improve the developer experience? The analogy is similar to using a statically typed language vs dynamically typed. Most API tools are dynamically typed. You’re guessing the params and relying on the request to magically work at runtime, only for you to go back to stack overflow or the docs when it doesn’t.
We take the approach of defining parameters and the schema first. When you add a new parameter, you need to mention upfront if it’s required and what type it is (integer, string, boolean). While this can be painful in the beginning, it will save you and anyone you share this with the hassle of understanding how this API works.
Our app is cross-platform on web and desktop. Our desktop app is <20mb and built on top of Rust with Tauri, NextJS, and Supabase. We open source our code because we want to be transparent about how API requests and secrets are handled (all local IndexDB).
I built the first version of this at Robinhood when my colleagues were sharing bash scripts and internal APIs on slack to test things. I wanted to make it easier for anyone to use an API quickly and made use of our OpenAPI specs to generate a nice autocomplete API tool. Soon after, the Options team, then the Crypto team, and then the whole eng org at Robinhood adopted this tool!
Try it out at recipeui.com! Please star us on GitHub if you like the product https://github.com/RecipeUI/RecipeUI.
Perhaps leaving someone like me to wallow in his ignorance is just fine. But being very clear and concise about what is being offered, without relying on knowledge of another product, might attract more of the uninitiated to your offering.
Ultimately this is a rest client used for troubleshooting, debugging and developing RESTful applications (ie: it's use to connect to websites and APIs.
It honestly looks pretty useful and better than postman so I'll try it out since I work with things that require software like this
You're just not the target. No harm in that.
> But being very clear and concise about what is being offered
It already is, the huge screenshot and the verbiage used ("the open source Postman alternative with type safety") makes it pretty clear what it's about for people who might be interested.
I don't believe everything needs to be understandable by everyone. You don't need to "sell" specialized tooling to people who don't know what it's for.
- the buttons on the download page aren't readable in Orion browser (basically Safari) on desktop. The buttons appear empty as the contents are rendered several rems below, overlapping the text "See more options on Github". Disabling the style `.btn { flex-wrap: wrap; }` in the inspector fixes it for me, but I see animations and transitions attached to this class so I'd suspect those might be the root cause bc nothing else looks strange.
- After I downloaded for Mac Apple Chip and started up the software, it says it's several versions out of date and asks if it can update itself. While I'm glad it was able to do so instead of sending me back to the website, it's a strange experience.
We're still considering better typing solutions like ZOD or OpenAPI wrappers, but our focus right now is core feature parity as an API tool.
We'll do a better job with written documentation! We forgot that video isn't always a medium that people prefer.
I've recently encountered this same apparent strong preference for video at work (where I lead a platform team whose deliverables support dozens of other teams) and while I can accept it (and even embraced it as we create howto videos), it remains very strange to me. When engaging with new tech I always want to see code and well-organized prose, but if there's a video I usually can't be bothered -- because the quality and signal-to-noise ratio are so often terrible, and it's got terrible ergonomics for highlighting or sharing key takeaways.
Good reminder that creators often aren't representative of their target demographic, or even well-aligned with their preferences.
Oof, that's a hard one for me. I'm firmly in the "can't possibly learn anything technical" from a video category. Specifications and copious examples for me.
Personally, I think JSONSchema and OpenAPI are table stakes for a product such as this.
I also think an embeddable version which runs in browser would be killer, replacing swagger-ui.
Scripting is under Tests tab.
I've built oauth2 authorization flow to get the code and afterwards the access token.
First request Test script:
pm.expect(pm.response.code).to.equal(302);
var code = pm.response.body;
var location = pm.response.headers.get("Location");
if (location.match(/\\?code=([^&]+)/) === null) {
postman.setNextRequest(pm.info.requestName)
console.log("Request must be re-run. First time adfs wants to set some cookies, eh.")
} else {
var code = location.match(/\\?code=([^&]+)/)[1];
pm.environment.set("oauth2_authorizationcode", code);
}
pm.environment.set("oauth2_accesstoken", pm.response.json().access_token);
pm.environment.set("oauth2_refreshtoken", pm.response.json().refresh_token);
>The one piece of Postman that only Hoppscotch (a Postman fork) seems replicate that I definitely want is scripting.
Parent is talking about the lack of scripting in Postman alternatives.
You can do request chaining with Step CI (https://stepci.com) and Hurl (https://hurl.dev)
Following is the curl command I got from Postman export
curl --location --globoff 'https://api.fly.io/prometheus/my-fly-app/api/v1/query?query=count(fly_instance_filesystem_blocks{app%3D~%22%5Ety-.*-.*%24%22%2C%20mount!%3D%22%2F%22}%20*%20fly_instance_filesystem_block_size{app%3D~%22%5Ety-.*-.*%24%22%2C%20mount!%3D%22%2F%22}%20%3E%201500000000)%20by%20(app)' \
--header 'Authorization: Bearer fo1_don_worry_this_is_changed_CjXvYYmWQIhDJE' \
--header 'User_Key: avinassh' \
--header 'Content-Type: application/json' \
--data '{"query": 12}'
{
"query": "count(fly_instance_filesystem_blocks{app"
}
I'm using Thunder Client in VS Code at the moment, but if my needs become more complicated I don't want to invest in anything douchey.
Not the OP, but for me the big pain points with Postman are
* Sync-ing with an OpenAPI spec is one-and-done. If new stuff is added to the spec, you have to start a new collection and throw away all your existing work (or in practise add the new APIs by hand)
* Many times I need to execute a sequence of requests to do anything useful. For example, I might need to get a list of objects, scan the list and pick the one i want to interact with, take the ID, copy-paste it to a different request, etc. Some requests I want to interact with I might need to grab 3 or more IDs from different endpoints. It's possible to improve this somewhat with Postman collections but I've always found them to be a lot of effort to set up, flaky, and cumbersome.
Next time I reach for Postman I will give this a go but it's not clear from the demo video if/how it addresses either of these problems.
I don't use VS Code and didn't try VSC plugins but the FOSS alternatives are not up to the same level of quality of Postman. Hoppscotch (formerly Postwoman) has some bugs. The best tool I know and recommend is HTTPie the Desktop version (or CLI version for CLI lovers). It stills partly open-source, not a free software.
I've never thought of an API exploration tool to be a marketplace of ready-baked API collections.
The speed is there, the UI can be improved, the selling point is "wooosh" on me.
But years after the ratification of this standard, pretty much no tools fully support it, and the code-generation toolchain is a pathetic joke. When I explored it further, I found that this state was well-known in the development community, and that even mentioning an attempt to use the OpenAPI tools was a professional liability... as in nobody who knows WTF they're doing would use this shit.
The best OpenAPI-definition tool I found was Stoplight Studio, which never supported OAS 3.1 and has since been pulled from the "market." They have a Github repo that claims to be the app, but contains none of the source and is only... the documentation? I called them out on it and got only an attitude, and the repo is still up and claiming to be the whole tool. Assholes.
However we've worked around it. We write most of our spec by hand. We thought it would be horrible but it's not.
All our APIs accept and respond with JSON so the OpenAPI payloads are pretty much JSON schemas which means we can parse and load them up in our functional tests and automate the schema validation as part of a functional test suite. We catch a lot of unintended changes to API contract with this approach (customer is now customer_id because serializer decided so and stuff like that).
Our team has OpenAPI specs but we have a rough time sending requests because each team member has valid requests for some subset of the API surface of a given service (from working on subsets of the service) and there isn’t a common repository for valid requests covering the entire surface area. On top of that there’s multiple forms of auth so there’s a flow to execute to obtain the auth token for a given request. Every team member has written their own scripts in various languages for one or more flavors of auth. We’re often sending each other one-off scripts or postman collection exports, or sharing fiddler traces or even tokens.
Would RecipeUI benefit us more than Postman?
Exporting your data from Postman has been made more difficult over the last few releases and now the local scratchpad is about to be removed in favor of using the free account in two weeks time.
These actions make me worry that Postman will soon no longer be a free tool or will use my collections and data for their own purposes (e.g. AI training).
I need an alternative, and maybe RecipeUI can fill that gap. Or I will be stuck on Insomnia.
I was under the impression that you could continue using scratchpad so long as you didn't sign in (Which I never felt the need to).
We're closely working on an API Storybook that'll be more native to a codebase and a service. Would love to reach out and hear more about your Postman experience!
Basically if you sign into postman, it's copying everything to their cloud. It "works" without signing in, but you can't use workspaces which means it saves things only in an unstructured sort of draft format.
That said, I'd consider switching for type-safety (or more specifically auto-completion) if there was an ability to e.g. import existing OpenAPI schema and automatically pick up the types.
The basic functionality starts off pretty easy to build so there's a large pool of people who decide to take a crack at it.
Being able to share schemas with colleagues would be great.
Currently secrets are just stored locally on desktop and web via IndexDB. I'd love to hear people's thoughts on this as well!
Does the desktop app make direct HTTP requests to target resources? Or are they similarly to web-app proxied through recipeui.com?
Plus, is there a way for the web-app to bypass that proxy, when the target resource allows that in CORS (naturally)(or when there is some browser extension that does it on dev's side)?
Unique to Restfox
- a nice "beautify json" button
- in addition to response code and time, shows size and exact timestamp of response
- Can drag and drop to reorganize folders and items in sidebar
Unique to RecipeUI
- TypeScript interface definitions
- Generates cURL, Javascript and Python code snippets you can copy
Probably other things, but these are what stood out.
Many API tools are lightweight reskins of Postman and we truly wanted to offer something different. Which is why we're leading with a type-safety angle and we're looking to innovate with other ideas! +1 to @easygenes comment's below
Ultimately went with Tauri because more people need to push the needle with alternatives and wanted to be there. Most ppl that build electron apps can definitely use Tauri because they're probably not writing much backend code.
I'm going to check this out!
I like that receipeui got rid of electron. I don't like the UI design very much as of right now at least... I would also need to know more (can you sort collections by projects? Can you store URL prefixes in environment/config variables?)
One thing I liked with Insomnia was being able to switch between development/production projects simply by switching the environment (no need to duplicate requests across collections).
I don't care for the Typescript types though... but I see how that could be useful for people.
I ditched postman years ago for Rest Client then now HTTPYAc
The fact that you also have typescript defs for the URL parameters is a nice touch though.