hyperium

hyperium/http

Rust Apache-2.0 Dev Tools

Rust HTTP types

1.4k stars
369 forks
recent
GitHub +3 / week

1.4k

Stars

369

Forks

177

Open issues

30

Contributors

v1.4.1 25 May 2026

AI Analysis

The `http` crate provides foundational Rust types for HTTP—Request, Response, StatusCode, headers, and URIs—without prescribing an I/O strategy. It is best suited for library and framework authors who need a shared, dependency-light HTTP type abstraction; end-user applications typically depend on it transitively through higher-level frameworks like Hyper or Tokio, rather than directly.

Dev Tools Library Discovery value: 3/10
Documentation 7/10
Activity 7/10
Community 8/10
Code quality 7/10

Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.

Overall score 8/10

AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.

http-types rust-stdlib type-abstraction zero-copy async-compatible
Actively maintained Well documented Niche/specialized use case Production ready
Deep Analysis · Based on README and public signals
1w ago

Low-level HTTP primitives library providing foundational types for Rust HTTP ecosystems

The `http` crate provides a minimal, zero-copy set of HTTP type definitions (Request, Response, StatusCode, Headers, etc.) for Rust. It is intentionally upstream of full HTTP implementations like Hyper and is used as a dependency by HTTP client/server frameworks to maintain API compatibility without coupling to specific implementations. Adoption appears substantial but largely invisible—embedded deep in dependency chains rather than used directly by end applications.

Origin

Created in 2017 as part of the Hyperium project ecosystem. Designed to separate HTTP type definitions from transport/protocol implementation, allowing multiple HTTP stacks (Hyper, Actix, Tokio, etc.) to interoperate via a common type vocabulary.

Growth

Growth has been steady but modest (1,360 stars, 2 gained in last 7 days). This reflects its role as infrastructure: high adoption doesn't translate to visibility because it's rarely chosen explicitly—it's inherited as a transitive dependency. The slow star growth is expected for foundational types; saturation is reached early and maintained thereafter.

In production

Adoption not formally documented in README, but indirect evidence is strong: the crate is listed as a dependency by Hyper (16K stars), H2 (1.5K stars), and likely numerous downstream frameworks. Crates.io version history and dependency graphs would confirm scale, but README contains no case studies or user testimonials.

Code analysis
Architecture

Appears to be a lightweight, purely-typed crate providing builder patterns for HTTP primitives. Based on README examples, the design follows Rust's type-safety paradigm with struct builders (Request::builder(), Response::builder()). Likely no network I/O, protocol parsing, or async runtime—strictly data structures.

Tests

Not documented in README.

Maintenance

Last push 2026-06-16 (17 days before evaluation date) indicates active maintenance. Project maintains MSRV 1.57 aligned with Hyper's policy, suggesting discipline. CI badge present. Update cadence appears regular but infrequent—consistent with a stable, mature foundational library.

Honest verdict

ADOPT IF: you are building an HTTP library, framework, or tool in Rust and need a dependency-light, stable type contract that interoperates across the ecosystem. AVOID IF: you need a complete HTTP implementation—use Hyper, Reqwest, or Actix instead; `http` provides only types. MONITOR IF: you are considering standardizing HTTP types across a polyglot codebase or unsure whether your dependency chain already pulls `http` in transitively (likely it does).

Independent dimensions

Mainstream potential

3/10

Technical importance

7/10

Adoption evidence

6/10

Risks
  • Tight coupling to Rust language evolution; MSRV changes could break downstream users if not managed carefully.
  • No formal governance or RFC process visible in README; changes may lack broad ecosystem input.
  • Type definitions lack semantic richness (e.g., no validation of header names/values at the type level)—consumer responsibility to enforce rules.
  • Upstream of high-traffic projects (Hyper, etc.); bugs or API changes have wide blast radius despite small team.
  • Documentation and examples minimal; most users learn through indirect dependency, not direct study.
Prediction

Will remain a stable, essential foundational layer for Rust HTTP tooling. Growth will remain flat or decline slightly as ecosystem matures and dependency graphs stabilize. No signs of replacement or significant API evolution needed.

0 found this helpful

Newsletter

Get analyses like this every Monday

Free weekly digest of the most interesting open-source discoveries.

Languages

Rust
100%

Information

Language
Rust
License
Apache-2.0
Last updated
3w ago
Created
113mo ago
Analyzed with
anthropic/claude-haiku-4-5

Stars over time

Loading…

Contributors over time

Top 100 contributors only — repos with more will plateau at 100.

Loading…

Similar repos

hyperium

hyperium/hyper

hyper is a low-level, production-grade HTTP library for Rust that implements...

16.2k Rust Dev Tools
hyperium

hyperium/h2

h2 is a Tokio-aware HTTP/2 protocol implementation for Rust, providing both...

1.5k Rust Dev Tools
algesten

algesten/ureq

Ureq is a lightweight, synchronous HTTP client library for Rust that...

2.2k Rust Dev Tools
hydro-project

hydro-project/hydro

Hydro is a Rust framework for building distributed systems with formal...

1.3k Rust Dev Tools
vs. alternatives
hyperium/hyper

Hyper is a full-featured HTTP client/server implementation; `http` is its upstream type dependency. They are complementary, not competitive. Hyper re-exports `http` types for user-facing APIs.

hyperium/h2

H2 is the HTTP/2 protocol implementation; `http` provides the type layer beneath it. Same complementary relationship.

serde (or similar serialization libs)

`http` does not overlap—it provides structure, not serialization. These are orthogonal.

tonic (gRPC framework)

Tonic likely depends on `http` indirectly; it is not a replacement but a higher-level abstraction built atop shared types.