Closed elandau closed 8 years ago
Thanks @elandau !
Adding context from the 0.5.0 issue #303
This implementation assumes that request execution can be modeled as a Func1<Request, Observable
>
Kind of yes, this is the API:
HttpClientRequest<I, O> createGet(String uri)
where HttpClientRequest
is an extension to Observable
, such as
public abstract class HttpClientRequest<I, O> extends Observable<HttpClientResponse<O>>
So, I can think of these interceptors as part of the HttpClientRequest
, eg:
RxNetty.createHttpClient()
.createGet("http://localhost:8999/hello")
.intercept((request, next) -> {
return next.call(request.addHeader("foo", "bar"));
})
.intercept((request, next) -> {
return Observable.error(new IllegalArgumentException("I dont like your request!));
})
.intercept((request, next) -> {
return next.call(request)
.addHeader("foo", "bar"); // This API is not yet there i.e. to change response
})
In this way chaining is implicit (order in which you add the interceptors) and hence does not require a different abstraction.
The most popular RESTful API specification Swagger implemented REST over WebSocket using the Atmosphere interceptor. Considering that Atomosphere was one of the fianlists of the Most innovative Java Technology of the JAX Innovation Awards 2014, you may want to take a look at the interceptors of Atmosphere and Nettosphere.
Hi Kant, If we use TcpClient to send a custom protocol request, maybe also need interceptor. If you add to HttpClientRequest, how to reuse it? Also i want to know if native RxJava Observal abstraction have a intercept method?
Interceptors are now available in the current snapshot and the examples can be found in rxnetty-examples module both for TCP & HTTP.
The following proposal addresses the need for an interceptor/filter model that can allow requests and responses to be replaced, modified or hooked into. Use cases of interceptors include logging, caching, request augmentation (such as adding HTTP headers) and Hystrix. This implementation assumes that request execution can be modeled as a
Func1<Request, Observable<Response>>
. Interceptors are 'configured' or applied as an ordered list.Request execution contract,
Each specific client implementation will have a single request execution class for the client's specific API. For example,
The Interceptor contract extends the basic execution contract by making it possible to iterate through a list of Interceptors to construct the final request Observable stream.
Interceptors are chained together as follows,
Example of a logging interceptor that doesn't modify the original request but does augment the returned Observable to log every stage during request execution.
Example of a failure injecting interceptor that may optionally stop processing the interceptor chain, transform the response and introduce delays into request execution,
Base contract for interceptors that just modify the request
For example, this interceptor adds an HTTP header to every outgoing request