Excited to try this out. A couple things I just noticed:

- 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.

Really nice embarrassing catches, thank you for flagging and debugging!!! Patch fixed both of these :)

Why would you post this here instead of the github page?

Because the founders came here and solicited feedback and he provided feedback directly to them.

I feel like those days are long past.

I don't think those days ever really existed.

Sure, lots of people (myself included) used to refuse to run windows, refuse to use any micro$hit software or anything bill g@te$ wrote and would loudly decry them.

But, the reality is, most people just ran whatever their employer gave them and for many many years that was almost definitely Microsoft stuff (especially on the desktop OS and core productivity suite).

Now I think the universe is just more pragmatic and we realize we can and should meet people where they are and arguing over tooling is just bikeshedding, at least I have.

I'm never going to ask people to please stop emailing spreadsheets and send me links to spreadsheets we can all edit online together, but, I no longer care if you send me gdocs or excel.

I'm no longer going to reply to your email with a .doc file with copypasta about how bill gates and microsoft are evil.

But, I'm firmly into grey beard territory these days so maybe i've just grown up but I do think (and hope) most of the internet has too.

Eh, no. They passed for a bit when Microsoft seemed to be playing nice and accepting the fact that the world has moved on from Windows.

Now they've regressed.

This is nice! I am enjoying it so far. Earlier, I was trying to find Postman alternatives and I went back to Postman because of UI quirks. I found couple of issues with RecipeUI

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}'

I could not import this in RecipeUI, says 'Could not parse CURL' it works fine on my terminal. I manually built this URL in RecipeUI, then I took the curl export and pasted in the URL bar. It did import now, but the data is truncated, my query param is just:

   {
      "query": "count(fly_instance_filesystem_blocks{app"
    }

Another problem: I want a low friction way to create new tab / Session. I could not find any keyboard shortcuts and also, no shortcuts to switch between sessions

Why were you looking for a Postman alternative? I thought it was open-source.

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.

I'm not sure if it's open, but it's trying hard to sell you on Postman Inc's cloud collaboration products.

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.

Thanks. I have been hugely disappointed by the state of OpenAPI tools.

Postman isn't free, it's proprietary and expensive (~19$ per user per month).

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.

There's also insomnia

This needs a button to import an OpenAPI spec (2.0, 3.0, doesn't matter) and let the user go wild on his own APIs.

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.

Yes. The OpenAPI ecosystem is in a shockingly shambolic state. I was charged with creating an API for my company's line of network-enabled products, so I defined it in OAS 3.1.

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.

Yes, the tooling around OpenAPI spec is not great.

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).

You can also use your OpenAPI spec to generate tests for the API

eg. with Step CI (https://stepci.com): https://docs.stepci.com/import/openapi.html

Will follow up tomorrow! Our initial product had import OpenAPI schema, but we temporarily removed it after finding a few bugs.

I haven’t downloaded RecipeUI yet to give it a try, but plan to. Does RecipeUI support importing OpenAPI specs in order to enforce type safety? I personally don’t like watching demos and prefer to read documentation. This information wasn’t available from the site.

Looking forward to your feedback when you use it! Currently we validate with mappings from TypeScript to JSONSchema. OpenAPI is definitely a gold standard, but I think JSONSchema is fairly strong as well.

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.

> "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.

For people reading this, just remember that people who prefer videos over prose aren't hanging out in a text-only forum like this. There's some self-selection happening here.

You should not automatically assume that most people prefer text over video!

No, but you can guess that people actually doing work and creating software do. I don't want to watch a fucking video when I can refer to actual documentation and potentially cut and paste some example code somewhere.

I happen to know other folks who also “actually do work” who prefer watching a video explainer. I usually prefer text, but sometimes people document features better in vocal conversation vs writing.

Also it's still hard to search through videos

You may try cast.ts. It is similar to zod but the parser has .type property which expose the typescript type of the validator, and .sampleValue property which expose a sample value. So you can access the metadata at runtime, which can be reused by other tools like yours.

> We forgot that video isn't always a medium that people prefer.

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.

Just an advice: Be careful with Postman. It seems they upload all your secrets to their servers. We stopped to use it a time ago. I don't know if they changed in this regard.

That's true. Details are here: https://learning.postman.com/docs/getting-started/basics/syn...

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.

data is encrypted in motion and at rest https://www.postman.com/trust/security/

By unstructured I mean "no workspaces", so you can't organize any of it. Like a filesystem with one folder called "stuff".

I've seen quite a few Postman alternatives pop up recently (quite curious what's the reasoning behind that?). Currently I'm mostly using Hoppscotch - also open-source with pretty sweet UI, and Thunder Client in VS Code.

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.

My guess at the Postman-alikes. Postman has evolved way past its original usefulness and is aggressively trying to push enterprise features and anything to make the business sustainable. I'm not mad at them for that but eventually you remember that you just wanted a graphical curl to mess with, not a team secret manager with workspaces and a test runner etc.

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.

Will follow up tomorrow! Our initial product had import OpenAPI schema, but we temporarily removed it after finding a few bugs.

After taking a quick look, I still don't know what this is, what Postman is, or who would use either, or for what. No doubt I could spend a bit more time to sort it out, but it would be nice to not have to.

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.

To be fair this is a fairly niche product, and anyone who is in the market for it will know postman.

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

> what Postman is

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.

I would argue the offering is actually very clear. A nice demo is included. If you’re not using any REST clients it might be a bit harder to understand but I doubt you’re the intended target group

> I would argue the offering is actually very clear.

What is it?

My take: RecipeUI a Postman-like tool that offers convenient type safety and autocomplete on top of what Postman already does.

What is Postman? It's a tool that allows you to configure, save, and replay HTTP requests. It helps developers building backend server APIs, so they don't have to keep fiddling around with their frontend. In many greenfield projects, the frontend doesn't even exist yet and Postman is effectively the only way to easily test what you're working on.

The alternative to postman is writing custom Python/NodeJS/etc programs to send these requests or painfully doing it with curl and bash.

I think it's cool and I'll probably try it the next time I have to work on REST APIs.

Honestly I'm still not entirely sold on the idea of Postman, for sending a simple HTTP request I find the python requests library a lot more intuitive to work with.

Then again I'm mostly looking at APIs to eventually use them in some other python script so perhaps my use case is not the best fit.

Unless the API does something weird you can do a lot worse than using curl and bash. I mean even using telnet (or openssl s_client) is not too bad if you're only doing a simple GET.

Postman is great for sharing API collections with others, especially if they aren’t a developer. Adding type safety to it is a great way to provide hints for acceptable values.

> on top of what Postman already does

The question was what that is.

"What does Foo do?" -- "Well just like what Bar does?" -- <no clue about Bar either>

Literally, the next 3 words from the quote answers your question.

> What is Postman? It's a tool that allows you to configure, save, and replay HTTP requests.

I've used it a lot whenever I've needed to integrate with a third party through a REST api. Postman for me is the playground where I build the queries and play with iteratively as I develop the integration.

Also, the webdev should try the page someday with a browser that has an aspect ratio of less than 2:1.

That import via curl was awesome! Something not hard to do by hand but such a time saver.

I'm going to check this out!

The one piece of Postman that only Hoppscotch (a Postman fork) seems replicate that I definitely want is scripting. Often requests depend upon data from another, and being able to put things into the environment as you run different requests is super useful (even if you just use it for otherwise unsupported auth methods).

I didn't quite understand if you are aware, but Postman has scripting and can depend upon data from another. And even can query it serially if you add requests to folder, right click on folder and "Run folder".

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);
  }

Second request Test script:

  pm.environment.set("oauth2_accesstoken", pm.response.json().access_token);
  pm.environment.set("oauth2_refreshtoken", pm.response.json().refresh_token);

Scripting: https://learning.postman.com/docs/writing-scripts/script-ref...

That's why parent wrote that Hopscotch is the only solution which replicated Postman scripting.

>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.

Hoppscotch is not a Postman fork as far as I know.

You can do request chaining with Step CI (https://stepci.com) and Hurl (https://hurl.dev)

or use Postman Flows https://learning.postman.com/docs/postman-flows/gs/flows-ove...

Your experience at Robinhood is relatable but I’m not sure I follow how RecipeUI would benefit us more than Postman.

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?

Postman is moving more and more from a local tool tp a cloud-based tool under the company's control.

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.

>and now the local scratchpad is about to be removed in favor of using the free account in two weeks time.

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).

Currently, we're not convincing enough for the team use case that tackles many of the things you're describing (especially auth). Thanks for the feedback!!!

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!

Interesting timing since Insomnia just died on me with the recent flatpak update (apparently my LTS linux install doesn't have the correct glibc, so goodbye Insomnia I guess).

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.

If you are a VSCODE user I would also look at https://httpyac.github.io/guide/installation_vscode.html

I ditched postman years ago for Rest Client then now HTTPYAc

Looks promising, can it import/export typescript interfaces?

Being able to share schemas with colleagues would be great.

We're thinking of a way to sync this with git or some link to a schema somewhere (e.g an OpenAPI yaml spec).

For now, you'll have to manually write the TypeScript interfaces but we'll support sharing APIs soon!

Look at app.QuickType and their abilities

I love the typescript definitions! I do have to say the way that pasting anything into the URL bar deletes the existing URL is super painful! I just wanted to change the variable case :(

The fact that you also have typescript defs for the URL parameters is a nice touch though.

Any plans to add GraphQL support? Feels like it would be a great match, since in many cases you can fetch the schema directly from the URL.

GraphQL is in our timeline for the next 2 weeks! Let us know if you have a favorite GraphQL API so we can add it in our public collection.

Your youtube video is an awesome demo. Congrats!

Looks great! Would love if there were a flatpak available to take this for a spin.

Maybe you want a Typescript SDK more than a HTTP endpoint.

It seems postman has put collections behind a paywall so timing for this is great. Does ReceipeUI manage secrets or have some suggestions to deal with this to avoid things leaking into shared cloud storage?

Storing secrets in the cloud has been a top concern for me, which is why we don't do it and one of the main reasons why the code is open sourced.

Currently secrets are just stored locally on desktop and web via IndexDB. I'd love to hear people's thoughts on this as well!

One related thing I haven't learned from a glance at the pitch and GH:

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)?

Desktop App is better because it directly makes the request!

Web app will have a custom proxy filter or just allow you to make the request if CORS is not an issue soon. We’ll add this to a settings panel.

Thanks for being this up, we’ll make this more specific on our GitHub

genuinely curious - how does Typescript help in autocomplete ? i thought it was equally fast using function name.

Is this any better than Insomnia?

Great work, looks awesome!

Looks great!

Have you seen hoppscotch[1]? They have been my postman alternative for quite some time now.

[1] https://hoppscotch.io

Hoppscotch is great! We have the same mindset as the founder that most API tools are outdated and were built a long time ago.

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

Every Postman alternative I've tried so far has choked on very large responses. Looking forward to giving this a try and seeing how it fares.

How large? Hundreds of megabytes? Gigabytes? More?

Another alternative I've been meaning to try out: https://restfox.dev/

So comparing the two...

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.

Restfox works right in the browser, no additional downloads needed, it seems.

That can also be a downside: CORS. Restfox recommends a browser extension to workaround that, and now we're back to additional downloads.

Getting rid of electron was the best thing.

I was almost convinced to use electron because it uses the same language as the frontend (JS) and has "better" support for production apps.

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.