retrofit

A library for generating REST APIs for functions.

Currently supports generating get and post APIs.

When the #[get_api] or #[post_api] macro is used, a request function is generated using reqwasm if on wasm or reqwest otherwise, and a rocket route.

Usage

```rust // Initial function

[post_api]

fn plus(num1: i32, num2: i32) -> i32 { num1 + num2 }

// Normal usage let result = plus(9, 10);

// Calling the function from client side let result = plus_request(9, 10).await;

// Mounting the route on the server

[launch]

fn rocket() -> _ { rocket::build().mount("/", routes![plus_route]) }

// The same works with GET APIs, but usually POST is recommended because it is more robust and can handle Vecs

[get_api]

fn minus(num1: i32, num2: i32) -> i32 { num1 - num2 }

// State can also be used!

[post_api(ConnectionPool)]

pub fn getallcustomers(pool: &ConnectionPool) -> Result, Error> { Ok(customers::table.limit(i64::MAX) .load::(&mut pool.get().unwrap())?) } // In this example, ConnectionPool is mounted on the rocket server, and does not need to be passed in to the request function ```

The example above generates a lot of code in the background. To get a better understanding of what Retrofit does, lets look at what's generated in the GET request minus function.

Code Generated

```rust // From above

[get_api]

fn minus(num1: i32, num2: i32) -> i32 { num1 - num2 }

// Everything below this point is generated.

// Route generated

[get("/minus//")]

fn minusroute(num1: String, num2: String) -> String { serdejson::tostring( &minus( serdejson::fromstr(&num1).unwrap(), serdejson::from_str(&num2).unwrap() ) ).unwrap() }

// Request function generated async fn minusrequest(num1: i32, num2: i32) -> i32 { serdejson::fromstr( &reqwest::get( &format!("http://localhost:8000/{}/{}", "minus", serdejson::tostring(&num1).unwrap(), serdejson::to_string(&num2).unwrap() ) ).await.unwrap() .text().await.unwrap() ).unwrap() } ```

Feature Flags

server - contains generated Rocket routes

client - contains generated request function

These features serve as a way to use the same code on a server and client. By default they are both enabled, but if you have functions with a generated API in a crate of your own, and you use client/server feature flags, you can import the same crate on both backend and frontend, and your backend code won't be packaged with frontend code. This is usefull if you are targeting WASM on the frontend and using a DB system like Diesel (not supported on WASM) for your backend.

Todo