DokumentePreiseBlog
Kontaktieren Sie uns
AnmeldenKOSTENLOS anmelden
Back to Tech Articles

Aufbau eines widerstandsfähigen und typsicheren Rust-API-Clients mit reqwest und serde

Juli 18, 2025
# Misc

Wenhao Wang

Dev Intern · Leapcell

Dieser Beitrag ist auch in English, 日本語 und 한국어 verfügbar
Cover of "Aufbau eines widerstandsfähigen und typsicheren Rust-API-Clients mit reqwest und serde"

Einleitung

In der heutigen vernetzten Softwarelandschaft interagieren Anwendungen häufig über APIs mit externen Diensten. Während die Durchführung von HTTP-Anfragen und das Parsen von Antworten eine grundlegende Aufgabe ist, kann dies zuverlässig und mit Vertrauen in die Datenintegrität überraschend schwierig sein. Manuelles Parsen führt oft zu Boilerplate-Code, potenziellen Laufzeitfehlern aufgrund falscher Annahmen über Datenstrukturen und einer schwierigen Fehlersuche. Dies gilt insbesondere in einer Sprache wie Rust, in der Typsicherheit ein Eckpfeiler ihrer Designphilosophie ist.

Dieser Artikel befasst sich damit, wie man einen robusten und typsicheren API-Client in Rust erstellt, indem man die Stärken zweier prominenter Crates nutzt: reqwest für die Abwicklung der HTTP-Kommunikation und serde für effiziente und zuverlässige Daten serialisierung und deserialisierung. Durch die Kombination dieser leistungsstarken Tools können wir Clients erstellen, die nicht nur leistungsfähig sind, sondern auch Compile-Zeit-Garantien für die mit externen APIs ausgetauschten Daten bieten, wodurch die Wahrscheinlichkeit von Laufzeitfehlern erheblich reduziert und die Produktivität der Entwickler verbessert wird.

Kernkonzepte erklärt

Bevor wir in die Implementierung eintauchen, lassen Sie uns die zentralen Konzepte, die unserem API-Client zugrunde liegen, kurz definieren.

  • HTTP-Clients: Im Kern sendet ein API-Client HTTP-Anfragen (GET, POST, PUT, DELETE usw.) an einen Remote-Server und empfängt HTTP-Antworten. reqwest ist ein beliebter, ergonomischer und async-first HTTP-Client für Rust. Er kümmert sich um Low-Level-Netzwerkdetails, sodass wir uns auf die Anwendungslogik konzentrieren können.
  • Serialisierung: Dies ist der Prozess, eine In-Memory-Datenstruktur (wie eine Rust struct) in ein Format zu konvertieren, das für die Übertragung über ein Netzwerk oder die Speicherung (z. B. JSON, YAML, XML) geeignet ist. Wenn Daten an eine API gesendet werden, serialisieren wir unsere Rust-Daten in das von der API erwartete Format.
  • Deserialisierung: Das Gegenteil der Serialisierung, dies ist der Prozess der Konvertierung von Daten aus einem Übertragungs-/Speicherformat zurück in eine In-Memory-Datenstruktur. Wenn wir eine Antwort von einer API erhalten, deserialisieren wir deren Inhalt in unsere Rust-Typen.
  • serde: Dies ist das De-facto-Serialisierungs-/Deserialisierungs-Framework für Rust. Es bietet ein Derive-Makrosystem, das es Entwicklern ermöglicht, benutzerdefinierte Datentypen einfach zu serialisieren und deserialisieren, ohne manuelle Parsing-Logik schreiben zu müssen. Es unterstützt zahlreiche Formate über Ökosystem-Crates (z. B. serde_json, serde_yaml).
  • Typsicherheit: In Rust bedeutet Typsicherheit, dass der Compiler überprüft, ob Variablen gemäß ihren deklarierten Typen verwendet werden. Dies verhindert ganze Klassen von Fehlern, wie z. B. den Versuch, Zeichenkettenoperationen auf eine Zahl anzuwenden. Bei der Interaktion mit APIs stellt die Typsicherheit sicher, dass die von uns gesendeten und empfangenen Daten unseren Erwartungen entsprechen, und fängt Diskrepanzen zur Compile-Zeit anstelle zur Laufzeit ab.
  • Fehlerbehandlung: Ein robuster API-Client muss Fehler ordnungsgemäß behandeln, sei es aufgrund von Netzwerkproblemen, ungültigen Serverantworten oder API-spezifischen Fehlermeldungen. Rusts Result-Enum eignet sich hierfür perfekt und ermöglicht es uns, potenzielle Fehlerpfade explizit zu verwalten.

Aufbau des Clients: Prinzipien und Praxis

Unser Ziel ist es, einen API-Client zu erstellen, der die Eingabe- und Ausgabestrukturen der API klar als Rust-Typen definiert. Dies bietet starke Compile-Zeit-Garantien und macht den Code viel einfacher zu verstehen und zu warten.

Stellen wir uns vor, wir bauen einen Client für eine einfache "Todo"-API.

1. Projekt-Setup

Erstellen Sie zunächst ein neues Rust-Projekt und fügen Sie die notwendigen Abhängigkeiten zu Ihrer Cargo.toml hinzu:

[package]
name = "todo_api_client"
version = "0.1.0"
edition = "2021"

[dependencies]
reqwest = { version = "0.12", features = ["json"] } # JSON-Feature für reqwest aktivieren
serde = { version = "1.0", features = ["derive"] } # Derive-Feature für serde aktivieren
serde_json = "1.0"
tokio = { version = "1.0", features = ["full"] } # Für asynchrone Laufzeit
thiserror = "1.0" # Für robuste Fehlerbehandlung
  • reqwest mit dem json-Feature ermöglicht es uns, einfach JSON zu senden und zu empfangen.
  • serde mit derive aktiviert die leistungsstarken #[derive(Serialize, Deserialize)]-Makros.
  • serde_json ist die spezifische serde-Implementierung für JSON.
  • tokio bietet die notwendige asynchrone Laufzeit für reqwest.
  • thiserror hilft bei der Erstellung benutzerdefinierter Fehlertypen mit weniger Boilerplate.

2. Definieren von Datenstrukturen

Wir definieren Rust structs, die die JSON-Strukturen unserer Todo-API widerspiegeln. Diese Strukturen werden mit serde zu Serialize und Deserialize.

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
pub struct Todo {
    pub id: Option<u32>, // `Option`, da die ID beim Erstellen möglicherweise nicht vorhanden ist
    pub title: String,
    pub completed: bool,
    pub user_id: u32,
}

#[derive(Debug, Serialize)]
pub struct CreateTodo {
    pub title: String,
    pub completed: bool,
    pub user_id: u32,
}

#[derive(Debug, Deserialize)]
pub struct ApiError {
    pub message: String,
    pub code: u16,
}
  • Todo: Stellt ein von der API abgerufenes Todo-Element dar. Die id ist Option<u32>, da die API die ID normalerweise bei der Erstellung zuweist.
  • CreateTodo: Stellt die Daten dar, die zum Erstellen eines neuenTodos benötigt werden. Beachten Sie, dass dieses keine id-Feld hat.
  • ApiError: Eine generische Struktur zur Erfassung von Fehlerantworten von der API.

3. Benutzerdefinierte Fehlerbehandlung

Es ist entscheidend, einen spezifischen Fehlertyp für unseren Client zu definieren, um verschiedene potenzielle Fehler zu kapseln.

use thiserror::Error;

#[derive(Debug, Error)]
pub enum TodoClientError {
    #[error("HTTP-Anfrage fehlgeschlagen: {0}")]
    Reqwest(#[from] reqwest::Error),
    #[error("JSON-Antwort konnte nicht geparst werden: {0}")]
    Serde(#[from] serde_json::Error),
    #[error("API gab einen Fehler zurück: {message} (Code: {code})")]
    Api {
        message: String,
        code: u16,
    },
    #[error("Ungültige Basis-URL")]
    InvalidBaseUrl,
}
  • Wir verwenden thiserror, um automatisch Display und From-Traits für unser FehlermEnum zu implementieren.
  • #[from] ermöglicht die automatische Konvertierung von reqwest::Error und serde_json::Error, was die Fehlerweiterleitung vereinfacht.
  • Die Api-Variante ist für strukturierte API-Fehlerantworten gedacht und ermöglicht es uns, Kontext einzubeziehen.

4. Aufbau der Client-Struktur

Lassen Sie uns nun die TodoClient-Struktur und ihre Methoden erstellen.

use reqwest::Client;
use std::fmt::Display;

pub struct TodoClient {
    base_url: String,
    http_client: Client,
}

impl TodoClient {
    pub fn new(base_url: &str) -> Result<Self, TodoClientError> {
        let parsed_url = url::Url::parse(base_url)
            .map_err(|_| TodoClientError::InvalidBaseUrl)?;

        Ok(Self {
            base_url: parsed_url.to_string(),
            http_client: Client::new(),
        })
    }

    // Hilfsmittel zum Erstellen vollständiger URLs
    fn get_url<P: Display>(&self, path: P) -> String {
        format!(<ctrl63>public/json/rust-lang-org-blog-post-template.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.json.
    json = "json"
>
    // Hilfsmittel zum Erstellen vollständiger URLs
    fn get_url<P: Display>(&self, path: P) -> String {
        format!("{}/{}", self.base_url.trim_end_matches('/'), path)
    }

    pub async fn get_all_todos(&self) -> Result<Vec<Todo>, TodoClientError> {
        let url = self.get_url("todos");
        let response = self.http_client.get(&url).send().await?;

        if !response.status().is_success() {
            let api_error: ApiError = response.json().await?;
            return Err(TodoClientError::Api {
                message: api_error.message,
                code: api_error.code,
            });
        }

        let todos: Vec<Todo> = response.json().await?;
        Ok(todos)
    }

    pub async fn get_todo_by_id(&self, id: u32) -> Result<Todo, TodoClientError> {
        let url = self.get_url(format!("todos/{}", id));
        let response = self.http_client.get(&url).send().await?;

        if !response.status().is_success() {
            let api_error: ApiError = response.json().await?;
            return Err(TodoClientError::Api {
                message: api_error.message,
                code: api_error.code,
            });
        }

        let todo: Todo = response.json().await?;
        Ok(todo)
    }

    pub async fn create_todo(&self, new_todo: &CreateTodo) -> Result<Todo, TodoClientError> {
        let url = self.get_url("todos");
        let response = self
            .http_client
            .post(&url)
            .json(new_todo) // `reqwest` serialisiert automatisch mit `serde_json`
            .send()
            .await?;

        if !response.status().is_success() {
            let api_error: ApiError = response.json().await?;
            return Err(TodoClientError::Api {
                message: api_error.message,
                code: api_error.code,
            });
        }

        let created_todo: Todo = response.json().await?;
        Ok(created_todo)
    }

    // Sie können weitere Methoden für Update, Löschen usw. hinzufügen.
}

Erklärung:

  • TodoClient::new: Konstruktor, der eine Basis-URL entgegennimmt und den reqwest::Client initialisiert. Er führt eine grundlegende URL-Validierung durch.

  • get_url: Eine private Hilfsmethode zum Konstruieren vollständiger API-Endpunkte aus relativen Pfaden.

  • get_all_todos / get_todo_by_id:

    • Konstruiert die vollständige URL.
    • Verwendet self.http_client.get(&url).send().await?, um die GET-Anfrage zu stellen. Der ?-Operator leitet reqwest::Error weiter.
    • Fehlerbehandlung: Es wird response.status().is_success() geprüft. Wenn nicht erfolgreich, wird versucht, den Antwortkörper in unsere ApiError-Struktur zu deserialisieren und einen TodoClientError::Api zurückzugeben. Dies ist eine robuste Methode zur Behandlung strukturierter API-Fehler.
    • Wenn erfolgreich, deserialisiert response.json().await? die JSON-Antwort direkt in unsere Vec<Todo>- oder Todo-Struktur. Der ?-Operator behandelt serde_json::Error.

  • create_todo:

    • Verwendet post(&url) für eine POST-Anfrage.
    • json(new_todo) ist eine leistungsstarke reqwest-Methode, die jeden Serialize-Typ (CreateTodo in diesem Fall) entgegennimmt, ihn mit serde_json in JSON serialisiert und den Header Content-Type: application/json setzt.
    • Fehlerbehandlung und Deserialisierung der erfolgreichen Antwort ähneln denen von GET-Anfragen.

5. Anwendungsbeispiel

Lassen Sie uns unseren Client in Aktion sehen!

#[tokio::main]
async fn main() -> Result<(), TodoClientError> {
    // Eine gängige öffentliche Dummy-API zum Testen.
    // Ersetzen Sie dies durch Ihre tatsächliche API-Basis-URL.
    let base_url = "https://jsonplaceholder.typicode.com";
    let client = TodoClient::new(base_url)?;

    println!("---", );
    println!("Alle Todos werden abgerufen ---", );
    match client.get_all_todos().await {
        Ok(todos) => {
            for todo in todos.iter().take(5) { // Die ersten 5 zur Kürze ausgeben
                println!("{:?}", todo);
            }
        }
        Err(e) => eprintln!("Fehler beim Abrufen aller Todos: {}", e),
    }

    println!("\n---", );
    println!("Todo mit ID 1 wird abgerufen ---", );
    match client.get_todo_by_id(1).await {
        Ok(todo) => println!("{:?}", todo),
        Err(e) => eprintln!("Fehler beim Abrufen des Todos nach ID: {}", e),
    }

    println!("\n---", );
    println!("Neues Todo wird erstellt ---", );
    let new_todo = CreateTodo {
        title: "Rust API Client lernen".to_string(),
        completed: false,
        user_id: 1,
    };
    match client.create_todo(&new_todo).await {
        Ok(created_todo) => println!("Erstelltes Todo: {:?}", created_todo),
        Err(e) => eprintln!("Fehler beim Erstellen des Todos: {}", e),
    }

    // Beispiel für die Behandlung eines erwarteten API-Fehlers (z. B. nicht vorhandene ID)
    println!("\n---", );
    println!("Nicht vorhandenes Todo wird abgerufen (ID 99999) ---", );
    match client.get_todo_by_id(99999).await {
        Ok(todo) => println!("Nicht vorhandenes Todo gefunden: {:?}", todo), // Sollte nicht passieren
        Err(e) => {
            eprintln!("Erwarteter Fehler beim Abrufen eines nicht vorhandenen Todos: {}", e);
            if let TodoClientError::Api { message, code } = e {
                println!("API-Fehlerdetails: Nachricht='{}', Code={}", message, code);
            }
        }
    }


    Ok(())
}

Diese main-Funktion zeigt, wie man:

  • Den TodoClient instanziiert.
  • Seine asynchronen Methoden aufruft.
  • Sowohl erfolgreiche Ok-Ergebnisse als auch verschiedene Err-Varianten mithilfe von match behandelt.
  • Speziell TodoClientError::Api behandelt, um strukturierte API-Fehlerantworten zu inspizieren.

Wichtige Vorteile dieses Ansatzes

  1. Typsicherheit: Alle API-Anfragen und -Antworten sind stark typisiert. Wenn sich die API ändert, markiert Rusts Compiler Inkonsistenzen zwischen Ihren struct-Definitionen und der tatsächlichen JSON-Struktur zur Compile-Zeit und verhindert so subtile Laufzeitfehler.
  2. Robuste Fehlerbehandlung: Explizite Fehlertypen und Result garantieren, dass alle potenziellen Fehlerpfade berücksichtigt werden, von Netzwerkproblemen über falsch formatierte JSON-Daten bis hin zu API-spezifischen Fehlern.
  3. Lesbarkeit und Wartbarkeit: Der Code definiert klar die erwarteten Datenformen und Interaktionen mit der API, was ihn für andere leichter verständlich und für zukünftige Änderungen erleichtert.
  4. Reduzierter Boilerplate: serdes Derive-Makros und reqwests .json()-Helfer reduzieren die Menge an manuellem Parsing- und Serialisierungscode erheblich.
  5. Asynchron nach Design: Nutzt Rusts async/await für nicht-blockierende I/O, was für reaktionsfähige Anwendungen unerlässlich ist.

Fazit

Der Aufbau eines robusten, typsicheren API-Clients in Rust ist machbar und äußerst vorteilhaft. Indem wir unsere Datenstrukturen sorgfältig mit serde definieren und reqwest für eine leistungsstarke und ergonomische HTTP-Kommunikation nutzen, können wir Clients entwickeln, die widerstandsfähig gegenüber Änderungen sind, starke Compile-Zeit-Garantien bieten und die Produktivität der Entwickler erheblich verbessern. Dieser Ansatz befähigt uns, mit Zuversicht mit externen Diensten zu integrieren, in dem Wissen, dass die Datenintegrität unserer Anwendung von der Netzwerkschicht bis zur Anwendungslogik gewahrt bleibt.

Share this article

HackerNews

More Posts from Leapcell

cover

Absicherung von Rust-Webanwendungen gegen Timing-Angriffe und gängige Schwachstellen

cover

Robuste Transaktionsverwaltung mit SQLx und Diesel in Rust

Popular Posts