Rust + Warp 1이 포함된 REST API: 소개

Rust를 위한 몇 가지 좋은 웹 프레임워크 옵션이 있습니다: actix, 로켓, 조수, 워프... 그리고 그것들은 모두 일종의 절충안을 제공합니다. 그러나 이러한 복잡한 측면을 주의 깊게 분석하는 대신(Luca가 here을 수행한 것처럼), Start Trek에 대한 명시적 참조가 있는 항목을 사용하기로 결정했습니다. 맞죠? 이상하지 않아, 친구, 이상하지 않아... 내가 당신을 비난할까요? 아니요. 당신은 나에게서 지원을 받을 수 있을 것입니다.

그리고 당신은 이미 이 길을 걷고 있기 때문에 warp을 직접 사용하여 REST API를 만든 방법을 보여주는 것이 좋을 것 같습니다(홀로덱 전투처럼 학습 목적으로).

Please note that this is not a tutorial; this is me sharing a process in the hopes that it can help you. Imagine you ask a friend to help you build something. This friend can either point you to the guides she someday used or show you how she actually went about it, not only sharing the code but explaining the whys and hows. This text is a simulation of the latter. In other words, if examples like these are enough to get you going, considering using them instead of reading this somewhat long text (unless you are easily amused by Star Trek references and puns, then stay).

아직 탈 준비가 되었나요? 엄청난! 얼 그레이 차(뜨거운!)를 잡고 그렇게 합시다!

시작하기

먼저 놀이터.

$ cargo new --lib holodeck

이제 (적어도) 두 가지 방법이 있습니다. 첫 번째는 Bastian이 한 것처럼 API를 제공하고 curl을 통해 테스트하는 것입니다. 이를 위해 바이너리 크레이트를 사용합니다. 다른 방법은 워프에 내장된 테스트 기능을 사용하는 것인데, 라이브러리를 얻는 것이 가장 좋다고 생각합니다. 내 주요 목표 중 하나는 실제로 warp의 테스트 모듈을 시도하는 것이었기 때문에 두 번째 경로를 선택했습니다.
Cargo.toml 파일을 편집하고 2개의 here 을 추가하여 시작했습니다.

[dependencies]
tokio = { version = "1", features = ["full"] }
warp = "0.3"

그런 다음 아주 간단한 테스트 케이스를 작성했습니다. 나는 둔한 GET 방법을 테스트하기로 결정했습니다. 무딘 것은 실제로 데이터를 반환하지 않는다는 것을 의미합니다. [1] 필터가 추가될 filters이라는 모드가 있을 것이라고 가정합니다(필터는 dependencies과 같이 워프 사용의 등쪽 척추입니다). [2]; 요청을 사용하여 가정된 필터를 사용하여 경로 GET에 /holodeck을 만듭니다. [3] 마지막으로 답을 열거형 StatusCode::ACCEPTED 과 비교합니다. 그리고 모든 것이 비동기식일 것이기 때문에 #[tokio::test]이 필요합니다.

#[cfg(test)]
mod tests {
    use warp::http::StatusCode;
    use warp::test::request;
    use super::filters;

    #[tokio::test]
    async fn try_list() {
        let api = filters::list();

        let response = request()
            .method("GET")
            .path("/holodeck")
            .reply(&api)
            .await;

        assert_eq!(response.status(), StatusCode::ACCEPTED);
    }
}

You will notice that I chose not to write use super::filters::* with the *, which would allow me to write things like list() instead of filters::list(); I did so because it makes it easier for me (and for you) to know what is coming from where.

그런 다음 빈 GET만 예상하도록 설계된 누락된 필터를 만들고 "Matthew McConaughey 처리기"라고 부르는 것으로 처리하도록 설계되었습니다. 왜냐하면 here(일명 StatusCode::ACCEPTED)이라고 말하는 것뿐이기 때문입니다.

mod filters{
    use warp::Filter;
    use super::handlers;

    pub fn list() ->  impl Filter<Extract = impl warp::Reply, Error = warp::Rejection> + Clone{ 
        warp::path!("holodeck")
            .and(warp::get())
            .and_then(handlers::handle_list)
    }
}

mod handlers{
    use warp::http::StatusCode;
    use std::convert::Infallible;

    pub async fn handle_list() -> Result<impl warp::Reply, Infallible> {
        // "Alright, alright, alright", Matthew said.
        Ok(StatusCode::ACCEPTED)
    }
}

핸들러의 결과에 Infallible이 있는 이유는 무엇입니까? 무언가 잘못되면(아직 코딩되지 않음) 문제도 Ok로 전송되기 때문입니다(예: Ok(StatusCode::BAD_GATEWAY) ).

많은 시간을 낭비하는 것처럼 보일 수 있지만 이 작업을 수행할 때의 이점을 알려 드리겠습니다. 우선, 때때로(어쩌면 매번) 우리가 무엇을 해야 하는지보다 무엇을 하고 싶은지 아는 것이 더 쉬우며 테스트는 무수히 많은 가능성에 뛰어들기 전에 이 "무엇"에 답하도록 강제하는 좋은 방법입니다. "방법"질문에 대한 답변입니다. 게다가, 이러한 베이비 단계를 통해 어떤 기능이 어떤 작업을 담당했는지, 누가 비동기식이어야 하고 누가 하지 않았는지 등을 명확하게 파악할 수 있었습니다.

$ cargo test

running 1 test
test tests::try_list ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

그것은 효과가 있었다; 많은 일이 일어나지 않았지만 그럼에도 불구하고 일했습니다.

알았어 알았어 알았어 Engaging Warp의 다음 에피소드에서...

다음 단계는 POST 메소드를 빌드하는 것입니다. 이를 위해서는 필터와 핸들러 모두를 적절하게 코딩하고 JSON을 역직렬화하고 어딘가에 저장해야 합니다.

어쨌든 지금은 여기까지입니다. 내가 잘못 말했거나 일을 해야 하는 것보다 더 복잡하게 만들었다면 댓글로 알려주십시오.

🖖