feat(service): introduce hyper-specific Service
#1490
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
sfackler
reviewed
Apr 18, 2018
| /// An asynchronous function from `Request` to `Response`. | ||
| pub trait Service { | ||
| /// The `Payload` body of the `http::Request`. | ||
| type ReqBody: Payload; |
There was a problem hiding this comment.
Doesn't Hyper control what type the request body is?
There was a problem hiding this comment.
True. I'd like to bring the implementation back for Client, which will need to define the ReqBody. I'm just unsure about how best to move forward to tower::Service, which has a poll_ready function (and may be changing soon)...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This introduces the
hyper::servicemodule, which replacestokio-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 isHTTP. Instead, the request and response bodies are associated types now,
and slightly stricter bounds have been placed on
Error.The helpers
service_fnandservice_fn_okshould be sufficient fornow to ease creating
Services.The
NewServicetrait now allows service creation to also beasynchronous.
These traits are similar to
towerin nature, and possibly will bereplaced completely by it in the future. For now, hyper defining its own
allows the traits to have better context, and prevents breaking changes
in
towerfrom affecting hyper.Closes #1461
BREAKING CHANGE: The
Servicetrait has changed: it has some changedassociated types, and
callis now bound to&mut self.The
NewServicetrait has changed: it has some changed associatedtypes, and
new_servicenow returns aFuture.Clientno longer implementsServicefor now.hyper::server::conn::Servenow returnsConnectinginstead ofConnections, sincenew_servicecan now return aFuture. TheConnectingis a future wrapping the new service future, returninga
Connectionafterwards. In many cases,Future::flattencan beused.