Introduce interceptors for RestTemplate [SPR-7494]

[spring-projects-issues]

Arjen Poutsma opened SPR-7494 and commented

The RestTemplate will benefit from having interceptor-style delegates, similar to the Spring-WS ClientInterceptors (see http://static.springsource.org/spring-ws/sites/1.5/apidocs/org/springframework/ws/client/support/interceptor/ClientInterceptor.html)

---

Attachments:

• spring-extensions.zip (12.00 kB)

Issue Links:

• HTTP cache and conditional requests support in RestTemplate [SPR-5821] #10491 HTTP cache and conditional requests support in RestTemplate ("is depended on by")
• RestTemplate cannot support OAuth [SPR-6143] #10811 RestTemplate cannot support OAuth ("is depended on by")

1 votes, 6 watchers

[spring-projects-issues]

Duane Zamrok commented

I've attached a maven project that contains code to implement this feature. The project contains interfaces and classes to describe a HttpContext and extends the existing Spring 3.0.3 org.springframework.web.client.RestTemplate class.

The major shortcoming, so far as I can tell, of this code base is that the org.springframework.web.client.ExtendedRestTemplate does not account for the fact that the org.springframework.http.client.SimpleClientHttpResponse and the org.springframework.http.client.CommonsClientHttpResponse both maintain a single java.io.InputStream as their body. This is a shortcoming because it means that if a HttpClientInterceptor reads the body of the org.springframework.web.client.context.HttpMessageContext#getResponse then the input stream will be closed when the org.springframework.http.client.ExtendedRestTemplate attempts to extract the response. I've implemented a workaround to this problem with the org.springframework.http.client.RepeatableClientHttpResponse, and demonstrated its use with the org.springframework.web.client.interceptor.LoggingHttpClientInterceptor, but it remains a problem that must be adressed by the interceptor.

Note:
This could be resolved by using a org.springframework.http.client.RepeatableClientHttpResponse directly in the org.springframework.http.client.ExtendedRestTemplate#doExecute method, but doing so would add unecessary overhead to the call for cases where there are no interceptors and/or the interceptors do not need to access the response body.

[spring-projects-issues]

Duane Zamrok commented

I think the ClientHttpResponse, at least, could benefit from having a method along the lines of "isBodyRepeatable" to denote whether or not it is safe to read the InputStream returned by "getBody" more than once.

I've been thinking about this problem a little bit more, and noticed a problem with the LoggingHttpClientInterceptor. The interceptor will wrap the response without testing to see if it is a RepeatableClientHttpResponse. This means that if a RepeatableClientHttpResponse is received by the LoggingHttpClientInterceptor it will be wrapped inside of yet another RepeatableClientHttpResponse. To avoid this I would need to specifically test to see if the resposne I recieved is a RepeatableClientHttpResponse; which feels rather tightly coupled to a specific implementation. Without the fix however I will waste both memory and CPU on a task that is unnecessary.

Please don't take offense to the following, because I think the foundations of Spring 3.0 are way better than anything I could have done myself. However I think the ClientHttpResponse, ClientHttpRequest, HttpInputMessage, and HttpOutputMessage interfaces are all a little bulky compared to the spring-ws implementations. I'm sure it is because the interfaces were not written with multiple consumers in mind, but even so it makes working with them an exercise in extreme caution. I used my debugger extensivly to ensure that the stream states were not violated, and the LoggingInterceptor only works when the body of the request is a ByteArrayOutputStream.

[spring-projects-issues]

Arjen Poutsma commented

Fixed by adding a ClientHttpRequestInterceptor interface, which can be set on the RestTemplate

[spring-projects-issues]

Brian Relph commented

What about adding response interceptors? Even if the issues around the response body inputstream remain unresolved, I see value in being able to inspect the headers ...

[spring-projects-issues]

Arjen Poutsma commented

@Brian: you can actually change the response with this ClientHttpRequestInterceptor as well, see

https://fisheye.springsource.org/browse/~raw,r=3930/spring-framework/trunk/org.springframework.web/src/main/java/org/springframework/http/client/ClientHttpRequestInterceptor.java

Soon, Keith will write a blog entry about these interceptors and how they are used in Spring Social to provide OAuth authentication to the RestTemplate.

[spring-projects-issues]

Francisco Lozano commented

PLS back-port this to Spring Android's rest-template

[spring-projects-issues]

Arjen Poutsma commented

@Francisco: feel free to report an issue against the ANDROID project at https://jira.springsource.org/browse/ANDROID

[spring-projects-issues]

Roy Clarkson commented

Interceptors are already available in Spring Android.

http://static.springsource.org/spring-android/docs/1.0.x/api/org/springframework/http/client/ClientHttpRequestInterceptor.html

[spring-projects-issues]

chanwook park commented

@Arjen Poutsma
this link is not available..
https://fisheye.springsource.org/browse/~raw,r=3930/spring-framework/trunk/org.springframework.web/src/main/java/org/springframework/http/client/ClientHttpRequestInterceptor.java
by your comment.
did you fix link?