Trait ntex::Service[][src]

pub trait Service {
    type Request;
    type Response;
    type Error;
    type Future: Future;
    fn poll_ready(&self, ctx: &mut Context<'_>) -> Poll<Result<(), Self::Error>>;
fn call(&self, req: Self::Request) -> Self::Future; fn poll_shutdown(&self, ctx: &mut Context<'_>, is_error: bool) -> Poll<()> { ... }
fn map<F, R>(self, f: F) -> Map<Self, F, R>
    where
        F: FnMut(Self::Response) -> R
, { ... }
fn map_err<F, E>(self, f: F) -> MapErr<Self, F, E>
    where
        F: Fn(Self::Error) -> E
, { ... } }
Expand description

An asynchronous function from Request to a Response.

Service represents a service that represanting interation, taking requests and giving back replies. You can think about service as a function with one argument and result as a return type. In general form it looks like async fn(Req) -> Result<Res, Err>. Service trait just generalizing form of this function. Each parameter described as an assotiated type.

Services provides a symmetric and uniform API, same abstractions represents clients and servers. Services describe only transforamtion operation which encorouge to simplify api surface and phrases value transformation. That leads to simplier design of each service. That also allows better testability and better composition.

Services could be represented in several different forms. In general, Service is a type that implements Service trait.

struct MyService;

impl Service for MyService {
     type Request = u8;
     type Response = u64;
     type Error = MyError;
     type Future = Pin<Box<Future<Output=Result<Self::Response, Self::Error>>>;

     fn poll_ready(&self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> { ... }

     fn call(&self, req: Self::Request) -> Self::Future { ... }
}

Service can have mutable state that influence computation. This service could be rewritten as a simple function:

async fn my_service(req: u8) -> Result<u64, MyError>;

Associated Types

Requests handled by the service.

Responses given by the service.

Errors produced by the service.

The future response value.

Required methods

Returns Ready when the service is able to process requests.

If the service is at capacity, then Pending is returned and the task is notified when the service becomes ready again. This function is expected to be called while on a task.

This is a best effort implementation. False positives are permitted. It is permitted for the service to return Ready from a poll_ready call and the next invocation of call results in an error.

There are several notes to consider:

  1. .poll_ready() might be called on different task from actual service call.

  2. In case of chained services, .poll_ready() get called for all services at once.

Process the request and return the response asynchronously.

This function is expected to be callable off task. As such, implementations should take care to not call poll_ready. If the service is at capacity and the request is unable to be handled, the returned Future should resolve to an error.

Calling call without calling poll_ready is permitted. The implementation must be resilient to this fact.

Provided methods

Shutdown service.

Returns Ready when the service is properly shutdowned. This method might be called after it returns Ready.

Map this service’s output to a different type, returning a new service of the resulting type.

This function is similar to the Option::map or Iterator::map where it will change the type of the underlying service.

Note that this function consumes the receiving service and returns a wrapped version of it, similar to the existing map methods in the standard library.

Map this service’s error to a different error, returning a new service.

This function is similar to the Result::map_err where it will change the error type of the underlying service. This is useful for example to ensure that services have the same error type.

Note that this function consumes the receiving service and returns a wrapped version of it.

Implementations on Foreign Types

Implementors