#![doc(html_root_url = "https://docs.rs/tower-service/0.3.0")]
#![warn(
missing_debug_implementations,
missing_docs,
rust_2018_idioms,
unreachable_pub
)]
//! Definition of the core `Service` trait to Tower
//!
//! The [`Service`] trait provides the necessary abstractions for defining
//! request / response clients and servers. It is simple but powerful and is
//! used as the foundation for the rest of Tower.
use std::future::Future;
use std::task::{Context, Poll};
/// An asynchronous function from a `Request` to a `Response`.
///
/// The `Service` trait is a simplified interface making it easy to write
/// network applications in a modular and reusable way, decoupled from the
/// underlying protocol. It is one of Tower's fundamental abstractions.
///
/// # Functional
///
/// A `Service` is a function of a `Request`. It immediately returns a
/// `Future` representing the eventual completion of processing the
/// request. The actual request processing may happen at any time in the
/// future, on any thread or executor. The processing may depend on calling
/// other services. At some point in the future, the processing will complete,
/// and the `Future` will resolve to a response or error.
///
/// At a high level, the `Service::call` function represents an RPC request. The
/// `Service` value can be a server or a client.
///
/// # Server
///
/// An RPC server *implements* the `Service` trait. Requests received by the
/// server over the network are deserialized and then passed as an argument to the
/// server value. The returned response is sent back over the network.
///
/// As an example, here is how an HTTP request is processed by a server:
///
/// ```rust
/// # use std::pin::Pin;
/// # use std::task::{Poll, Context};
/// # use std::future::Future;
/// # use tower_service::Service;
///
/// use http::{Request, Response, StatusCode};
///
/// struct HelloWorld;
///
/// impl Service>> for HelloWorld {
/// type Response = Response>;
/// type Error = http::Error;
/// type Future = Pin>>>;
///
/// fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll> {
/// Poll::Ready(Ok(()))
/// }
///
/// fn call(&mut self, req: Request>) -> Self::Future {
/// // create the body
/// let body: Vec = "hello, world!\n"
/// .as_bytes()
/// .to_owned();
/// // Create the HTTP response
/// let resp = Response::builder()
/// .status(StatusCode::OK)
/// .body(body)
/// .expect("Unable to create `http::Response`");
///
/// // create a response in a future.
/// let fut = async {
/// Ok(resp)
/// };
///
/// // Return the response as an immediate future
/// Box::pin(fut)
/// }
/// }
/// ```
///
/// # Client
///
/// A client consumes a service by using a `Service` value. The client may
/// issue requests by invoking `call` and passing the request as an argument.
/// It then receives the response by waiting for the returned future.
///
/// As an example, here is how a Redis request would be issued:
///
/// ```rust,ignore
/// let client = redis::Client::new()
/// .connect("127.0.0.1:6379".parse().unwrap())
/// .unwrap();
///
/// let resp = client.call(Cmd::set("foo", "this is the value of foo")).await?;
///
/// // Wait for the future to resolve
/// println!("Redis response: {:?}", resp);
/// ```
///
/// # Middleware / Layer
///
/// More often than not, all the pieces needed for writing robust, scalable
/// network applications are the same no matter the underlying protocol. By
/// unifying the API for both clients and servers in a protocol agnostic way,
/// it is possible to write middleware that provide these pieces in a
/// reusable way.
///
/// Take timeouts as an example:
///
/// ```rust,ignore
/// use tower_service::Service;
/// use tower_layer::Layer;
/// use futures::FutureExt;
/// use std::future::Future;
/// use std::task::{Context, Poll};
/// use std::time::Duration;
/// use std::pin::Pin;
///
///
/// pub struct Timeout {
/// inner: T,
/// timeout: Duration,
/// }
///
/// pub struct TimeoutLayer(Duration);
///
/// pub struct Expired;
///
/// impl Timeout {
/// pub fn new(inner: T, timeout: Duration) -> Timeout {
/// Timeout {
/// inner,
/// timeout
/// }
/// }
/// }
///
/// impl Service for Timeout
/// where
/// T: Service,
/// T::Future: 'static,
/// T::Error: From + 'static,
/// T::Response: 'static
/// {
/// type Response = T::Response;
/// type Error = T::Error;
/// type Future = Pin>>>;
///
/// fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll> {
/// self.inner.poll_ready(cx).map_err(Into::into)
/// }
///
/// fn call(&mut self, req: Request) -> Self::Future {
/// let timeout = tokio_timer::delay_for(self.timeout)
/// .map(|_| Err(Self::Error::from(Expired)));
///
/// let fut = Box::pin(self.inner.call(req));
/// let f = futures::select(fut, timeout)
/// .map(|either| either.factor_first().0);
///
/// Box::pin(f)
/// }
/// }
///
/// impl TimeoutLayer {
/// pub fn new(delay: Duration) -> Self {
/// TimeoutLayer(delay)
/// }
/// }
///
/// impl Layer for TimeoutLayer
/// {
/// type Service = Timeout;
///
/// fn layer(&self, service: S) -> Timeout {
/// Timeout::new(service, self.0)
/// }
/// }
///
/// ```
///
/// The above timeout implementation is decoupled from the underlying protocol
/// and is also decoupled from client or server concerns. In other words, the
/// same timeout middleware could be used in either a client or a server.
///
/// # Backpressure
///
/// Calling a `Service` which is at capacity (i.e., it is temporarily unable to process a
/// request) should result in an error. The caller is responsible for ensuring
/// that the service is ready to receive the request before calling it.
///
/// `Service` provides a mechanism by which the caller is able to coordinate
/// readiness. `Service::poll_ready` returns `Ready` if the service expects that
/// it is able to process a request.
pub trait Service {
/// Responses given by the service.
type Response;
/// Errors produced by the service.
type Error;
/// The future response value.
type Future: Future