Satay

sans-IO OpenAPI 3.1 Rust 2024 MSRV 1.88

82 downloads 3 stars

OpenAPI clients without picking a transport

Satay turns a spec into request builders, response decoders, and validation newtypes. You send the http::Request with reqwest, ureq, hyper, or whatever you already run.

Install CLI View source

Quick start

shell
cargo install satay-cli
Satay logo: cubes on a skewer, standing in for OpenAPI, codegen, and transport adapters

Origin

Named for the skewer, not the sauce

sate

/ˈsɑː.teɪ/

n.

(Malay, Indonesian)

a skewer; meat (or other food) cut into pieces, threaded onto a skewer, and grilled.

English satay comes from the Malay and Indonesian word sate, which refers to both the skewer and the dish. Street vendors thread marinated pieces onto bamboo sticks, grill them over charcoal, and serve them with peanut sauce. The name caught on abroad as the dish spread across Southeast Asia.

Satay-rs leans into that image. OpenAPI describes the pieces: schemas, operations, constraints. Codegen threads them into typed request builders and response decoders. Your application picks the transport and sends them through. The skewer is the sans-IO boundary. The pieces stay the same no matter which grill you use.

  1. OpenAPI spec

    The marinated pieces: schemas, operations, constraints.

  2. Codegen

    Threads them into builders and decoders you can read.

  3. Your transport

    reqwest, ureq, hyper, tests, WASM, WebSocket, or your own client.

  4. sans-IO boundary

    The skewer itself. Same pieces, different grill.

Why sans-IO

Maintain the API, not the HTTP client

Most OpenAPI clients bundle a transport. Your SDK ends up tracking reqwest releases, TLS changes, and separate async, blocking, and WASM code paths. Satay generates the API layer only. You send the requests yourself.

Without sans-IO

  • Async, blocking, and WASM each need their own client code path
  • Security and feature changes in reqwest, hyper, or ureq become your release work
  • Swapping transports means refactoring the client internals
  • Tests often need real HTTP or heavy mocks around the whole stack

With Satay

  • One generated surface for building requests and decoding responses
  • Transport adapters are thin and optional. Your app keeps the HTTP client
  • Backend updates stay at the edge. Regenerate when the spec changes, not when reqwest bumps
  • Unit tests can build requests and decode responses without the network

You maintain only the OpenAPI spec. Satay turns it into typed Rust. When the API changes, update the spec and regenerate. Your HTTP client stays separate.

Features

Rust you can read, not template soup

Builders, decoders, and validation newtypes from your OpenAPI spec.

sans-IO first

Actions build plain http::Request values. Send them with reqwest, ureq, hyper, tests, WASM, or whatever you already run.

Validation newtypes

String, number, integer, and array constraints from the spec become nutype newtypes. Bounds narrow to u8 when the maximum allows it.

OpenAPI 3.1

Reads the spec into a normalized IR, then emits structs, enums, builders, and decoders as ordinary Rust you can edit.

Optional adapters

Stay IO-free, or pull in satay-reqwest and satay-ureq when you want a short send_with call site.

Built with Satay

In the wild

Open-source API clients built with Satay. Got one? Send a PR.

Add your project

Fork the repo, add a row to website/src/data/users.ts with your name, description, and links. Logo goes in public/users/ if you have one; set logo in the entry.

Submit via GitHub

How it works

Generate the client. Send it yourself.

  1. 01 Install the CLI and point it at your OpenAPI file.
  2. 02 Satay writes builders that produce IO-free http::Request values.
  3. 03 Send that request with reqwest, ureq, hyper, or your own client, then decode the response with the generated action types.
generate 
$ satay generate --input openapi.yaml --output src/generated --rustfmt
$ satay --help