feat(service): introduce hyper-specific Service
This introduces the `hyper::service` module, which replaces `tokio-service`. Since the trait is specific to hyper, its associated types have been adjusted. It didn't make sense to need to define `Service<Request=http::Request>`, since we already know the context is HTTP. Instead, the request and response bodies are associated types now, and slightly stricter bounds have been placed on `Error`. The helpers `service_fn` and `service_fn_ok` should be sufficient for now to ease creating `Service`s. The `NewService` trait now allows service creation to also be asynchronous. These traits are similar to `tower` in nature, and possibly will be replaced completely by it in the future. For now, hyper defining its own allows the traits to have better context, and prevents breaking changes in `tower` from affecting hyper. Closes #1461 BREAKING CHANGE: The `Service` trait has changed: it has some changed associated types, and `call` is now bound to `&mut self`. The `NewService` trait has changed: it has some changed associated types, and `new_service` now returns a `Future`. `Client` no longer implements `Service` for now. `hyper::server::conn::Serve` now returns `Connecting` instead of `Connection`s, since `new_service` can now return a `Future`. The `Connecting` is a future wrapping the new service future, returning a `Connection` afterwards. In many cases, `Future::flatten` can be used.
This commit is contained in:
Sean McArthur
@@ -5,10 +5,10 @@ extern crate pretty_env_logger;
|
||||
extern crate tokio;
|
||||
extern crate url;
|
||||
|
||||
use futures::{Future, Stream};
|
||||
use futures::{future, Future, Stream};
|
||||
|
||||
use hyper::{Body, Method, Request, Response, StatusCode};
|
||||
use hyper::server::{Server, Service};
|
||||
use hyper::{Body, Method, Request, Response, Server, StatusCode};
|
||||
use hyper::service::service_fn;
|
||||
|
||||
use std::collections::HashMap;
|
||||
use url::form_urlencoded;
|
||||
@@ -17,89 +17,80 @@ static INDEX: &[u8] = b"<html><body><form action=\"post\" method=\"post\">Name:
|
||||
static MISSING: &[u8] = b"Missing field";
|
||||
static NOTNUMERIC: &[u8] = b"Number field is not numeric";
|
||||
|
||||
struct ParamExample;
|
||||
// Using service_fn, we can turn this function into a `Service`.
|
||||
fn param_example(req: Request<Body>) -> Box<Future<Item=Response<Body>, Error=hyper::Error> + Send> {
|
||||
match (req.method(), req.uri().path()) {
|
||||
(&Method::GET, "/") | (&Method::GET, "/post") => {
|
||||
Box::new(future::ok(Response::new(INDEX.into())))
|
||||
},
|
||||
(&Method::POST, "/post") => {
|
||||
Box::new(req.into_body().concat2().map(|b| {
|
||||
// Parse the request body. form_urlencoded::parse
|
||||
// always succeeds, but in general parsing may
|
||||
// fail (for example, an invalid post of json), so
|
||||
// returning early with BadRequest may be
|
||||
// necessary.
|
||||
//
|
||||
// Warning: this is a simplified use case. In
|
||||
// principle names can appear multiple times in a
|
||||
// form, and the values should be rolled up into a
|
||||
// HashMap<String, Vec<String>>. However in this
|
||||
// example the simpler approach is sufficient.
|
||||
let params = form_urlencoded::parse(b.as_ref()).into_owned().collect::<HashMap<String, String>>();
|
||||
|
||||
impl Service for ParamExample {
|
||||
type Request = Request<Body>;
|
||||
type Response = Response<Body>;
|
||||
type Error = hyper::Error;
|
||||
type Future = Box<Future<Item = Self::Response, Error = Self::Error> + Send>;
|
||||
|
||||
fn call(&self, req: Request<Body>) -> Self::Future {
|
||||
match (req.method(), req.uri().path()) {
|
||||
(&Method::GET, "/") | (&Method::GET, "/post") => {
|
||||
Box::new(futures::future::ok(Response::new(INDEX.into())))
|
||||
},
|
||||
(&Method::POST, "/post") => {
|
||||
Box::new(req.into_body().concat2().map(|b| {
|
||||
// Parse the request body. form_urlencoded::parse
|
||||
// always succeeds, but in general parsing may
|
||||
// fail (for example, an invalid post of json), so
|
||||
// returning early with BadRequest may be
|
||||
// necessary.
|
||||
//
|
||||
// Warning: this is a simplified use case. In
|
||||
// principle names can appear multiple times in a
|
||||
// form, and the values should be rolled up into a
|
||||
// HashMap<String, Vec<String>>. However in this
|
||||
// example the simpler approach is sufficient.
|
||||
let params = form_urlencoded::parse(b.as_ref()).into_owned().collect::<HashMap<String, String>>();
|
||||
|
||||
// Validate the request parameters, returning
|
||||
// early if an invalid input is detected.
|
||||
let name = if let Some(n) = params.get("name") {
|
||||
n
|
||||
// Validate the request parameters, returning
|
||||
// early if an invalid input is detected.
|
||||
let name = if let Some(n) = params.get("name") {
|
||||
n
|
||||
} else {
|
||||
return Response::builder()
|
||||
.status(StatusCode::UNPROCESSABLE_ENTITY)
|
||||
.body(MISSING.into())
|
||||
.unwrap();
|
||||
};
|
||||
let number = if let Some(n) = params.get("number") {
|
||||
if let Ok(v) = n.parse::<f64>() {
|
||||
v
|
||||
} else {
|
||||
return Response::builder()
|
||||
.status(StatusCode::UNPROCESSABLE_ENTITY)
|
||||
.body(MISSING.into())
|
||||
.body(NOTNUMERIC.into())
|
||||
.unwrap();
|
||||
};
|
||||
let number = if let Some(n) = params.get("number") {
|
||||
if let Ok(v) = n.parse::<f64>() {
|
||||
v
|
||||
} else {
|
||||
return Response::builder()
|
||||
.status(StatusCode::UNPROCESSABLE_ENTITY)
|
||||
.body(NOTNUMERIC.into())
|
||||
.unwrap();
|
||||
}
|
||||
} else {
|
||||
return Response::builder()
|
||||
.status(StatusCode::UNPROCESSABLE_ENTITY)
|
||||
.body(MISSING.into())
|
||||
.unwrap();
|
||||
};
|
||||
}
|
||||
} else {
|
||||
return Response::builder()
|
||||
.status(StatusCode::UNPROCESSABLE_ENTITY)
|
||||
.body(MISSING.into())
|
||||
.unwrap();
|
||||
};
|
||||
|
||||
// Render the response. This will often involve
|
||||
// calls to a database or web service, which will
|
||||
// require creating a new stream for the response
|
||||
// body. Since those may fail, other error
|
||||
// responses such as InternalServiceError may be
|
||||
// needed here, too.
|
||||
let body = format!("Hello {}, your number is {}", name, number);
|
||||
Response::new(body.into())
|
||||
}))
|
||||
},
|
||||
_ => {
|
||||
Box::new(futures::future::ok(Response::builder()
|
||||
.status(StatusCode::NOT_FOUND)
|
||||
.body(Body::empty())
|
||||
.unwrap()))
|
||||
}
|
||||
// Render the response. This will often involve
|
||||
// calls to a database or web service, which will
|
||||
// require creating a new stream for the response
|
||||
// body. Since those may fail, other error
|
||||
// responses such as InternalServiceError may be
|
||||
// needed here, too.
|
||||
let body = format!("Hello {}, your number is {}", name, number);
|
||||
Response::new(body.into())
|
||||
}))
|
||||
},
|
||||
_ => {
|
||||
Box::new(future::ok(Response::builder()
|
||||
.status(StatusCode::NOT_FOUND)
|
||||
.body(Body::empty())
|
||||
.unwrap()))
|
||||
}
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
fn main() {
|
||||
pretty_env_logger::init();
|
||||
|
||||
let addr = ([127, 0, 0, 1], 1337).into();
|
||||
|
||||
let server = Server::bind(&addr)
|
||||
.serve(|| Ok(ParamExample))
|
||||
.serve(|| service_fn(param_example))
|
||||
.map_err(|e| eprintln!("server error: {}", e));
|
||||
|
||||
tokio::run(server);
|
||||
|
||||
Reference in New Issue
Block a user