This crate contains tools to enable Wasm Components to be called over HTTP. This should make it possible to convert WIT definitions into working HTTP APIs with little effort. Think: automatic SDK generation, and less remote objects. This means there will be some limitations: the only functions we'll be able to map over HTTP will be fallible, asynchronous functions. When executed remotely these functions reflect the realities of networking. But when executed locally, the asynchronous fallible interface can always be optimized out.
This project is a first attempt at defining what a bidirectional mapping of WIT and HTTP can look like. This is key to ensuring Wasm Components and WIT is not just restricted to intra-machine communication, but also inter-machine communication. If we have types on both sides, it should be able to generate the protocol to communicate between those types automatically.
| Status | Crate | Description |
|---|---|---|
| complete | wasi-async-runtime | WASI-based async runtime library for Rust |
| in-progress | openapi-bindgen | Generate bidirectional bindings between OpenAPI (Swagger) and WIT |
| in-progress | wasi-http-client | WASI-based HTTP client library for Rust |
| not yet started | wasm-http-tools | Rust tooling to use Wasm Components over HTTP |
| not yet started | wit-bindgen-http | Automatically generate HTTP routing layers for WIT definitions |
Want to join us? Check out our "Contributing" guide and take a look at some of these issues:
Licensed under Apache-2.0 WITH LLVM-exceptionUnless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license with LLVM-exception, shall be licensed as above, without any additional terms or conditions.