一个 HTTP Server 内部包含很多部分：协议完结（h1、h2、压缩等）、衔接状况办理（keepalive）、恳求分发、中间件、事务逻辑等。用户能够悉数自行完结，但其实除了事务逻辑之外的部分都是较为通用的才干。咱们将这些通用才干与用户的事务逻辑解耦，即 HTTP 结构。

因为 Rust 生态中 hyper 现已供给了较为完备的 HTTP 协议完结，依据 hyper 完结 HTTP 结构就只需求供给包含路由、同享状况、中间件等才干。

本文从 HTTP 结构的设计角度，以新版别 Axum 作为比方，剖析 Rust 下 HTTP 结构怎样供给合理笼统与类型束缚。依据 Rust 强壮的类型体系，咱们能够写出高效且正确的代码。

Handler 笼统

简略路由

通常关于不同恳求 Path 的不同 Method，咱们的行为是独立的。

依据 Path 和 Method 做分发归于 HTTP 结构需求供给的通用才干之一：比方咱们需求能够将 GET / 和 POST /login 分发到不同的处理函数上。

最简略的路由能够经过 HashMap 完结。如下所示，Key 是 Path 和 Method，Value 是对应的处理函数，Path 和 Method 咱们能够简略的用 String 来表明，处理函数该怎样表达呢？

HashMap<(Path, Method), Handler>

咱们先来处理 Handler 的问题，后面会从头评论更合理的路由设计。

因为咱们需求将 Handler 存储在 HashMap 中，所以咱们需求一个固定类型来表明它（不然 HashMap 的 Value 巨细无法确认）。在 Rust 中咱们常常运用 Box<dyn Trait> 来将不同的详细类型统一为同一类型（在其他语言中对应指针）。

这就要求咱们需求界说一个 Trait 来描绘处理逻辑。

最简略的计划: 束缚处理函数完结固定 Fn

因为处理逻辑一定是处理 HTTP Request，并得到 HTTP Response 的，所以一个直观的做法是直接将 hyper decode 出的 HTTP Request 结构作为参数，要求该函数回来 HTTP Response。

假如 handler 内部需求某个恳求参数，那么它需求自行从 HTTP Request 中取并或许需求自行做反序列化等处理（如 Json）。

add_route(handler: H, ...)
    where H: Fn(req: http::Request) -> http::Response { ... }

更用户友爱的接口

从前计划的缺陷是，用户运用十分麻烦，要自己提取参数。一个更用户友爱的完结是结构来处理参数提取，用户只需求在参数中声明自己需求的东西，以及描绘事务逻辑。

咱们期望的作用是：

async fn index() -> &'static str {
    "it works!"
}
async fn login(form: Form<...>) -> (StatusCode, String) { ... }

要将为这些 Handler 完结统一 Trait，咱们要处理这几个问题：

束缚每个参数都能从 HTTP Request 中提取到
束缚函数回来值能够转换到 HTTP Response
支撑变长参数（不同 Handler 的参数个数能够不一致）
支撑 Async Fn

参数束缚

咱们期望能够在经过编译查看保证这些参数能够从 Request 中提取到。咱们能够界说 Trait：

// framework code
pub trait FromRequest {
    type Error;
    fn from_request(req: &http::Request) -> Result<Self, Self::Error>;
}

例如关于需求从 HTTP Query 中提取参数的需求，用户就只需求完结这种代码：

// user code
#[derive(Deserilize)]
struct Filter {
    keyword: String,
    count: u32,
}
async fn search(Query(f): Query<Filter>) -> (StatusCode, String) { ... }

结构内完结辅佐结构 Query 完结从 Query 参数中提取。

// framework code
pub struct Query<Q>(pub Q);
impl FromRequest for Query<Q>
where ... {
    type Error = ...;
    fn from_request(req: &http::Request) -> Result<Self, Self::Error> { ... }
}

除了运用结构内建的 Query、Form 等辅佐结构，用户也能够自己完结 FromRequest。

经过这种方式，咱们将恳求参数提取与事务逻辑解耦，并做了类型束缚，保证该结构必须完结怎样从 Request 中抽取，该函数才完结 Handler，才干注册到 Router 上。

回来值束缚

回来值束缚和参数束缚相似，咱们束缚回来值能够转换为 Response:

pub trait IntoResponse {
    fn into_response(self) -> http::Response;
}

作为结构能够供给一些完结：

impl IntoResponse for &'static str {...}
impl IntoResponse for String {...}
impl IntoResponse for (StatusCode, String) {...}

借助 IntoResponse 咱们能够支撑用户 handler 回来自界说结构，将 Response 构建与事务逻辑解耦。

支撑变长参数

有的 handler 不需求什么输入参数（如前面说到的回来 “hello world” 的 index 接口），有的需求一个或多个 Request 中提取到的参数。

那么这类函数怎样统一笼统呢？在 Rust 中咱们惯用的操作是界说 Trait，并为满意条件的 Fn 完结这个 Trait。关于参数数量不同的 Fn，咱们需求手动为它们每个都完结 Trait。

因为这个工作单调无聊充溢重复，所以往往运用宏来完结，终究看起来代码块像是一个“梯形”。

// from axum
macro_rules! all_the_tuples {
    ($name:ident) => {
        $name!([], T1);
        $name!([T1], T2);
        $name!([T1, T2], T3);
        $name!([T1, T2, T3], T4);
        $name!([T1, T2, T3, T4], T5);
        $name!([T1, T2, T3, T4, T5], T6);
        $name!([T1, T2, T3, T4, T5, T6], T7);
        $name!([T1, T2, T3, T4, T5, T6, T7], T8);
        $name!([T1, T2, T3, T4, T5, T6, T7, T8], T9);
        $name!([T1, T2, T3, T4, T5, T6, T7, T8, T9], T10);
        $name!([T1, T2, T3, T4, T5, T6, T7, T8, T9, T10], T11);
        $name!([T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11], T12);
        $name!([T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12], T13);
        $name!([T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13], T14);
        $name!([T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14], T15);
        $name!([T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15], T16);
    };
}

咱们需求一个统一的调用接口，并运用宏完结它：

pub trait Handler {
    fn call(&self, req: http::Request) -> http::Response;
}
// illustrate for macro expand
impl<F, O> Handler for F
    where F: Fn() -> O, O: IntoResponse { ... }
// illustrate for macro expand result
impl<F, O, T1> Handler for F
    where F: Fn(T1) -> O, O: IntoResponse, T1: FromRequest {
    fn call(&self, req: http::Request) -> http::Response {
        let param1 = match T1::from_request(&req) {
            Ok(p) => p,
            Err(e) => return e.into(),
        };
        let resp = (self)(param1).into_response();
        resp
    }
}
// illustrate for macro expand
impl<F, O, T1, T2> Handler for F
    where F: Fn(T1, T2) -> O, O: IntoResponse, T1: FromRequest, T1: FromRequest { ... }
// other impl blocks ...

终究咱们调用时还是直接传入 http::Request 得到 http::Response。

Request 一切权问题

前面的接口中，咱们束缚恳求参数提取器只能拿到一个 Request 的只读引证，原因是咱们或许需求提取多个参数。这儿能够做一个小优化：假如只要一个参数提取器，那么传入一切权；不然对终究一个传入一切权，前面的传入引证。

在 Axum 内有两个相关 trait: FromRequestParts 和 FromRequest。FromRequestParts 能够从 HTTP Request Head 中提取内容（传递引证），FromRequest 能够从 HTTP Request Head 和 Body 中提取（传递整个 Request 的一切权）。FromRequest 关于需求消费 Body 的提取器来说十分友爱，但只会应用于终究一个提取器。

支撑 Async Fn

经过上一末节的 Handler Trait，咱们现已能够较为友爱地界说 Handler 了。可是往往咱们 handler 处理的过程会涉及数据库读写、下流 RPC 调用等，而这些网络操作是异步的，所以 handler 就不得不完结为 async fn。

Async Fn 本质上也是一个 Fn，和普通的 Fn 对比起来便是，async 解糖之后会将界说的回来值变为一个完结了 Future 的匿名结构，例如：

// before desuger
async fn example() -> String { ... }
// after desuger
fn example() -> AnonymousFut { ... }
struct AnonymousFut { ... }
impl Future for AnonymousFut {
    type Output = String;
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> { ... }
}

（延伸阅览：关于 Rust 异步体系的一些基础知识能够参考这个同享）

为了支撑 async fn 完结 Handler Trait，咱们需求做出一些改动：

pub trait Handler {
    fn call(&self, req: http::Request) -> BoxFuture<'static, http::Response>;
}

因为涉及到 Future 的详细类型，这儿其实咱们有两种做法：一种是将 type Future: Future<Output = http::Response> 作为 Trait 的相关类型，另一种是直接用 BoxFuture 将类型擦掉。

运用哪种主要取决于要不要擦除类型，以及想在哪里做类型擦除。一般来说，呈现或许嵌套调用的场景（比方 tower Service 嵌套），最好在终究做类型擦除，这样能够尽或许削减 Box 运用，增大能够内联的代码段以达到更好的性能。

咱们修正了 Trait，相同咱们需求修正完结。以下是宏展开后的一个 demo 比方：

// illustrate for macro expand result
impl<F, O, T1> Handler for F
    where F: Fn(T1) -> Fut, Fut: Future<Output = O>,
          O: IntoResponse, T1: FromRequest {
    fn call(&self, req: http::Request) -> BoxFuture<'static, http::Response> {
        Box::pin(async move {
            let param1 = match T1::from_request(&req) {
                Ok(p) => p,
                Err(e) => return e.into(),
            };
            let resp = (self)(param1).into_response();
            resp
        })
    }
}

注：这儿束缚了咱们一定要运用异步接口。假如要为回来 T: IntoResponse 的结构也完结 Handler，这样是有完结冲突的（因为都是 blanket impl）。

总结一下，这个末节里咱们界说清楚了 Handler Trait 并主动为用户界说的契合某些条件的 async fn / fn 完结了 Handler。用户能够在函数的参数和回来值上运用一些提取器和生成器，让 handler 自身专心于事务逻辑。

同享状况

Handler 内部或许会需求一些外部量，比方初始化好的 db、或许用于缓存的 HashMap 等。咱们一般会答应用户在创立 Route 的时候能够 attach 上某个 Stste（或许叫 Data），在 handler 函数参数中提取这个结构。

同享状况提取

咱们完全能够将同享状况视作 Request 的一部分。

这样咱们能够复用从前界说的 FromRequest。可是怎样区别咱们想提取的 S（这是一个用户界说的类型）到底从哪里提取到呢？或许说假如用户想提取的 S 便是咱们用于恳求参数提取的 Query 呢？假如直接将 S 放在参数中，这时语义上就会有歧义。

为了处理这个歧义，咱们能够定一个 State 类型。

pub struct State<S>(pub S);

之后为 State 完结 FromRequest 时，咱们便知道，这个 S 一定是要从同享状况中提取的。

同享状况存储

顺着咱们前面的思路，已然将同享状况视作 Request 的一部分，咱们要么将 state 放入 Request 的某个地方，要么界说一个新的带有 state 的 Request 或经过新增参数传入。

运用 Request 自身存储 State

在 Actix 和之前版别的 Axum 中，状况存储都是选用这种计划。Request 内部有一个 type map 叫 extension，咱们直接向其刺进一个 KV：key = S; val = S{…} 即可。在咱们提取时，运用 S 类型作为 key 即可查到咱们在调用 handler 之前刺进的这个 val。

看起来很方便且容易完结，可是这个计划抛弃了静态查看类型的机会。假如用户 handler 参数中需求的 State 和 Route 上 attach 的 State 类型不一致的话，就只能在运行时处理了。这样会导致错误的代码能够编译经过，但运行时 100% 出错。

经过新增参数传入并增加类型束缚

运用 Rust 的类型体系，咱们能够将前面说到的问题提前到编译期暴露。

咱们能够在 Handler、 FromRequest 和 Route 上增加泛型 S，并在 Route<S> 增加路由时做束缚：

pub trait Handler<S> {
    fn call(&self, req: http::Request, state: S) -> BoxFuture<'static, http::Response>;
}
pub trait FromRequest<S> {
    type Error;
    fn from_request(req: &http::Request, state: &S) -> Result<Self, Self::Error>;
}
pub struct Route<S> { ... }
impl<S> Route<S> {
    pub fn new(state: S) -> Self { ... }
    // we can only add Handler<S> to our self, not Handler<A> or Handler<B>
    pub fn route<H: Handler<S>>(self, hander: H) -> Self { ... }
}
// illustrate for macro expand result
impl<F, O, S, T1> Handler<S> for F
    where F: Fn(T1) -> Fut, Fut: Future<Output = O>,
          O: IntoResponse, T1: FromRequest {
    fn call(&self, req: http::Request, state: S) -> BoxFuture<'static, http::Response> {
        Box::pin(async move {
            let param1 = match T1::from_request(&req, &state) {
                Ok(p) => p,
                Err(e) => return e.into(),
            };
            let resp = (self)(param1).into_response();
            resp
        })
    }
}

这样咱们便能束缚 handler fn 上的 State 类型。终究咱们完结 State 辅佐结构用于参数提取：

pub struct State<S>(pub S);
impl<S> FromRequest<S> for State<S>
where S: Clone {
    type Error = Infallible;
    fn from_request(req: &http::Request, state: &S) -> Result<Self, Self::Error> {
        Ok(state.clone())
    }
}

功德圆满！咱们现在能够放心地运用同享状况而不用担心传错类型导致运行时出问题了。If it compiles, it works.

更用户友爱的同享状况

和咱们前面讲的从 Request 提取相同，用户或许仅仅需求 Request 或 State 中的一部分。为了让它更易用，咱们能够答应用户仅接纳 State 的一部分。例如：

struct MyShared {
    db: DBHandler,
    cache: Cache,
    counter: Counter,
}
async fn get_cache(State(cache): State<Cache>) -> String { ... }
async fn update_cache(State(cache): State<Cache>, State(db): State<DBHandler>) -> String { ... }

相似 FromRequest，咱们能够界说一个 Trait 答应从一个大结构衍生出子结构。

// in `from` style
pub trait FromRef<T> {
    fn from_ref(input: &T) -> Self;
}
// in `into` style
pub trait Param<T> {
    fn param(&self) -> T;
}

FromRef 与 Param 两种风格对比

相似 From 和 Into 的关系，咱们能够供给这两种风格的 Trait。这两种是等价的，只需求选择一种运用即可。

Axum 内运用 FromRef 这种界说，而 linkerd2-proxy 中咱们能够找到 Param 这种风格的界说。

这两种运用哪种比较好呢？这个就取决于自己喜好啦（标准库发起界说 From）～

注：这儿并不违反孤儿原则，虽然 FromRef 和 String 都不是咱们界说的，但因为 Example 是，所以 FromRef<Example> 不算 foreign type 。

struct Example {
    demo: String,
}
impl FromRef<Example> for String { ... }

或：

struct Example {
    demo: String,
}
impl Param<String> for Example { ... }

咱们选取 Into 风格的 Param Trait 来完结本末节的功用：

impl<S, I> FromRequest<S> for State<I>
where S: Param<I> {
    type Error = Infallible;
    fn from_request(req: &http::Request, state: &S) -> Result<Self, Self::Error> {
        Ok(state.param())
    }
}

路由

路由是对 Handler 的组合与分发体系。

之前咱们以一种最简略的路由引出了 Handler 概念，并介绍了 Handler Trait 束缚并依据宏主动给用户界说的函数完结了 Handler。但距离真实易用的路由还有一段距离。

路由查找与兼并

关于路由查找咱们能够运用现成的库 matchit。运用 matchit，它答应咱们注册 Path 和 Value，当咱们恳求匹配某个途径时，将契合的 Path 对应的 Value 回来给咱们。Matchit 依据 radix trie 完结，比起 HashMap 支撑前缀匹配和参数提取（如 /user/:id）。

简略完结的话，直接包装 matchit 即可做到途径匹配，但 matchit 的缺陷是不支撑遍历拿到注册时传入的 Path 和 Value。所认为了支撑更多的功用（如 merge），咱们就需求自己也保护一份全量的映射关系。

在 Axum 中，Handler 被表明为 Endpoint 类型。Router 中保护了两个信息：

RouteId → Endpoint
Node
1. matchit Router<RouteId>: 用于途径匹配
2. RouteId → Path
3. Path → RouteId

当查找途径时，直接丢给 matchit Router 查到对应的 RouteId，之后运用 RouteId 查找到 Endpoint。

当兼并路由时，假设咱们要将 B 兼并到 A，咱们会遍历 B 里的路由信息，得到一切的 (RouterId, Path, Endpoint) tuple，之后测验兼并到 A 中同 Path 上（关于 Path 相同 Method 不同的），假如不存在再另外创立新的。

例如，/login 和 /logout 兼并时，会向 matchit Router 中刺进对应 Path 和 RouterId；而 GET /login 和 POST /login 兼并时，就不需求修正 matchit Router，直接兼并对应 Endpoint 即可。

Endpoint

Axum 界说了 Endpoint 用于支撑嵌套 Route 和依据 Method 分发。

enum Endpoint<S, B> {
    MethodRouter(MethodRouter<S, B>),
    Route(Route<B>),
    NestedRouter(BoxedIntoRoute<S, B, Infallible>),
}

Route

pub struct Route<B = Body, E = Infallible>(BoxCloneService<Request<B>, Response, E>);

Route 是一个 async fn (Request) → Result<Response, Error>，它能够直接用来处理恳求。当咱们不需求依据 Method 做分发时，或许现已完结分发时，就能够直接将恳求打到对应 Route 上处理。

BoxedIntoRoute

pub(crate) struct BoxedIntoRoute<S, B, E>(Box<dyn ErasedIntoRoute<S, B, E>>);
pub(crate) trait ErasedIntoRoute<S, B, E>: Send {
    fn clone_box(&self) -> Box<dyn ErasedIntoRoute<S, B, E>>;
    fn into_route(self: Box<Self>, state: S) -> Route<B, E>;
    fn call_with_state(self: Box<Self>, request: Request<B>, state: S) -> RouteFuture<B, E>;
}

BoxedIntoRoute 擦掉了 Handler 类型，所以咱们在其泛型上找不到 Handler 相关的符号，或 Handler 的相关类型等。

其 State 是待填充的，咱们能够将 BoxedIntoRoute 理解为一个没有附加 State 的 Route。当附加 State 后它会变成一个真实的 Route，便是姓名里 Into Route 的含义。

MethodRouter

pub struct MethodRouter<S = (), B = Body, E = Infallible> {
    get: MethodEndpoint<S, B, E>,
    head: MethodEndpoint<S, B, E>,
    delete: MethodEndpoint<S, B, E>,
    options: MethodEndpoint<S, B, E>,
    patch: MethodEndpoint<S, B, E>,
    post: MethodEndpoint<S, B, E>,
    put: MethodEndpoint<S, B, E>,
    trace: MethodEndpoint<S, B, E>,
    fallback: Fallback<S, B, E>,
    allow_header: AllowHeader,
}
enum MethodEndpoint<S, B, E> {
    None,
    Route(Route<B, E>),
    BoxedHandler(BoxedIntoRoute<S, B, E>),
}

MethodRouter 内包含不同 Method 对应的 MethodEndpoint。MethodEndpoint 或许对应 None（该办法上没设置），也或许是从前说到的 Route 或 BoxedIntoRoute。

路由组合

咱们以一个从 axum 中抄来的 example 看一下 Router 到底怎样创立的：

async fn main() {
                ...
                let app = Router::new()
                    .route("/keys", get(list_keys))
                    .nest("/admin", admin_routes())
                    .with_state(Arc::clone(&shared_state));
                ...
}
async fn list_keys(State(state): State<SharedState>) -> String { ... }
fn admin_routes() -> Router<SharedState> {
    async fn delete_all_keys(State(state): State<SharedState>) { ... }
    async fn remove_key(Path(key): Path<String>, State(state): State<SharedState>) { ... }
    Router::new()
        .route("/keys", delete(delete_all_keys))
        .route("/key/:key", delete(remove_key))
        .layer(RequireAuthorizationLayer::bearer("secret-token"))
}

首要是 .route(“/keys”, get(list_keys))，这儿经过 get 将一个函数 Box 起来转为了 MethodRouter<S, B, Infallible>；之后经过 route 将其刺进到 Endpoint::MethodRouter 。因为当时还没附加 State，所以其内部类型对应 BoxedIntoRoute，即缺少 State 的那个类型。
之后咱们看 .with_state(Arc::clone(&shared_state))：

pub fn with_state<S2>(self, state: S) -> Router<S2, B> { ... }

这儿会附加 S 类型的 state 并重写泛型为新的类型 S2（S2 此刻没有任何束缚）。

with_state 内部会对一切 BoxedIntoRoute 附加 State 将其变为 Route 类型。

.nest 会接纳一个 prefix 和子路由。这时只需求将子路由作为 NestedRouter 刺进即可。需求注意的是这儿在丢给子路由之前，还需求额外去掉 prefix。

中间件

Tower Service

在介绍路由体系之前，咱们先来熟悉一下用到的组件。

Tower 是 Rust 生态中的一个通用逻辑描绘组件。Tower 供给一个 Service Trait 描绘一个输入 Request 输出 Result<Response, Error> 的异步逻辑。只要是一个输入对应一个响应的逻辑根本都能够用这个 Trait 描绘。

pub trait Service<Request> {
    type Response;
    type Error;
    type Future: Future<Output = Result<Self::Response, Self::Error>>;
    fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>>;
    fn call(&mut self, req: Request) -> Self::Future;
}

Service 不只能协助不同组件之间的接口对齐，咱们还能够运用 tower 的一些辅佐组件来做逻辑的组合。Tower 供给了 Layer 用于对 Service 做润饰，还供给了 Stack 用于 Layer 之间的嵌套。

pub trait Layer<S> {
    type Service;
    fn layer(&self, inner: S) -> Self::Service;
}
pub struct Stack<Inner, Outer> {
    inner: Inner,
    outer: Outer,
}
impl<S, Inner, Outer> Layer<S> for Stack<Inner, Outer>
where
    Inner: Layer<S>,
    Outer: Layer<Inner::Service>,
{
    type Service = Outer::Service;
    fn layer(&self, service: S) -> Self::Service {
        let inner = self.inner.layer(service);
        self.outer.layer(inner)
    }
}

简略总结一下便是：

Service 描绘了 async fn (Request) → Result<Response, Error> 的通用逻辑。
Layer 是 Service 的润饰器，传入一个 Service 能够回来一个润饰后的 Service。
Stack 是 Layer 的组合，其自身也完结了 Layer，在 .layer 时会依次调用内部的一切 layer。

因为咱们选用了 Service 中间件，而且 Route 自身完结了 Service，所以咱们接纳 layer 即可包装 Route。

关于当时还缺少 State 的 BoxedIntoRoute，咱们先将 layer 暂存起来，等候填充 State 后再 layer 包装。

Server 创立及运用

咱们将前面说到的路由、Handler 和中间件组合到一同，就构成一个 Server，Server 答应用户 bind 并 serve MakeService：

axum::Server::bind(&addr)
      .serve(router.into_make_service())
      .await;

IntoMakeService<S> 完结了 Service<T, Response = S, Error = Infallible>。

Server::bind(…).serve(…) 会创立出来一个 Server；Server 完结了 Future，所以能够直接 await。在其 Future 完结中，会首要 accept 衔接并运用 IntoMakeService<S> 生成 S，即用于处理恳求的 Service（便是咱们的 router）。

之后 io(衔接)会和处理 Service 一同包装在一个 hyper::Connecting 结构中，结构 hyper::NewSvcTask 并将这个 task spawn 出去。

衔接上的读写、解码等均由 hyper 负责，终究 hyper 运用将解码好的 http::Request 调用咱们传入的 Service，即 Router。

Router 和 State 的泛型 trick

到这儿本文现已根本剖析完了：

怎样束缚 Handler
怎样做路由查找与路由办理
怎样支撑同享状况

在阅览代码过程中，注意到 Axum 的有关 State 泛型的 trick，感觉很有新意。

假如你认真阅览了前面有关同享状况的部分，那么你会发现我的写法是这样的：

async fn index() -> String { ... }
let route = Route::new(state).route("index", get(index));

而 Axum 里支撑这种做法：

let route = Route::new()
    .route("1", get(index1))
    .with_state(s1)
    .route("2", get(index2))
    .route("2", post(index2))
    .with_state(s2)
    .route("3", post(index3))
    .with_state(s3)

Axum 中能够以链式的方式串起来不同的 Handler 和 State。这是怎样完结的呢？

Router 的 new 办法都没有对 S 加直接束缚，也便是说能够理解为这儿的 S 是 Any。当调用 route 办法时，Handler 完结或许会对 S 发生束缚（也或许不发生）。在调用 with_state 办法时，S 的类型会被确认下来，此刻：

会查看这个 S 能不能满意前面的束缚
重置泛型 S 为 S2（即清空相关，清空束缚）

终究在运用 router 时，会调用 into_make_service 而且会束缚 Router 完结 Service，而这两个完结都是对 Router<()> 的完结，即 S 能够为 ()。

咱们考虑下面几种情况：

前面注册的 handler 束缚了 S，但没有 with_state：此刻对 S 有束缚（这个束缚正常人不会写成 ()，不然没有意义），那么 S 就不或许为 ()，所以假如忘了附加 state 或许附加的 state 不对，那么就会编译失利。
前面注册的 handler 没有束缚 S，也没有 with_state：此刻对 S 没有束缚，所以 S 能够为 ()，那么即使没有调用 with_state ，相同是能编译经过的。
前面注册的 handler 束缚了 S，终究又 with_state：这时 with_state 将 S 束缚清空，所以 S 能够为 ()，编译经过。
和前面的比方相同链式调用：每次 with_state 都会清空前面的束缚，并在再次 .route 的时候增加束缚，但只要终究是 with_state 或终究的一系列 .route 没有对 S 加以束缚，那么 S 就能够为 ()，编译经过。

经过这种 trick，Axum 中做到了 State 的静态查看，并支撑在没有用到 State 的时候无需附加 State。

Rust HTTP 框架设计 – 以 Axum 0.6 为例

Handler 笼统

简略路由

最简略的计划: 束缚处理函数完结固定 Fn

更用户友爱的接口

参数束缚

回来值束缚

支撑变长参数

Request 一切权问题

支撑 Async Fn

同享状况

同享状况提取

同享状况存储

运用 Request 自身存储 State

经过新增参数传入并增加类型束缚

更用户友爱的同享状况

FromRef 与 Param 两种风格对比

路由

路由查找与兼并

Endpoint

Route

BoxedIntoRoute

MethodRouter

路由组合

中间件

Tower Service

Server 创立及运用

Router 和 State 的泛型 trick

作者信息

Rust HTTP 框架设计 – 以 Axum 0.6 为例

Handler 笼统

简略路由

最简略的计划: 束缚处理函数完结固定 Fn

更用户友爱的接口

参数束缚

回来值束缚

支撑变长参数

Request 一切权问题

支撑 Async Fn

同享状况

同享状况提取

同享状况存储

运用 Request 自身存储 State

经过新增参数传入并增加类型束缚

更用户友爱的同享状况

FromRef 与 Param 两种风格对比

路由

路由查找与兼并

Endpoint

Route

BoxedIntoRoute

MethodRouter

路由组合

中间件

Tower Service

Server 创立及运用

Router 和 State 的泛型 trick

相关文章

iOS小技能：调整导航条BarButtonItem与屏幕边界/titleView 的间距

springboot项目启动时如何排除一个bean？

Objective-C 类的分类(Category)与扩展(Extension)

我代码就加了一行log日志，结果引发了P1的线上事故

作者信息