Open
Description
This is issue about what appears at https://docs.rs/hyper. As a general rule, we should incrementally improve them with the following in mind:
- Types should have a description of what they are used for, not just a repeat of the type name.
- Methods should almost always include a code example.
- Modules should explain concepts of what its types are meant to be used for, and how to combine those types with others.
- If a question comes up more than once from a user, it should be somewhere in the API docs.
- If it is there, and people still ask, it's probably in the wrong place, or not written clearly.
Items to document
- lib 👀
- body
- client
- module: for the example, also link to the client guide.
-
conn
: 👀
- ext
- module: explain that the types in here go in request or response extensions
- struct
Protocol
: explain that it is for http/2, what it does, that it must be used with associated builder options, show example - struct
ReasonPhrase
- ffi: add
unstable
tag - rt
- module: better overview, subsections explaining executors, timers, and IO
- server
-
conn
module: mention hyper-util providing anAutoConnection
and builder -
conn::http1
module: provide an overview, and a getting started section - struct
conn::http1::Builder
: Provide an example constructing one and setting some options. - struct
conn::http1::Connection
: Explain that this is returned fromBuilder::serve_connection
, and that it is essential animpl Future
that must be polled (orawait
ed) for anything to happen. -
conn::http2
module: provide an overview, and a getting started section
-
- service 👀
- upgrade 👀