Comments on: REST in Spring 3: RestTemplate http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/ The voice of SpringSource Fri, 19 Mar 2010 05:36:47 -0500 http://wordpress.org/?v=2.8.5 hourly 1 By: JUnit Tests for Spring 3 Rest Services « Ralf Schäftlein’s Blog http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-171616 JUnit Tests for Spring 3 Rest Services « Ralf Schäftlein’s Blog Fri, 12 Mar 2010 08:35:08 +0000 http://blog.springsource.com/?p=1469#comment-171616 [...] MVC part of the Framework. Rest Service are defined as Controller and can be tested with the new Resttemplate. In this little sample project is Spring 3 combined with JUnit 4, Maven, Hibernate 3.2, Jetty, [...] [...] MVC part of the Framework. Rest Service are defined as Controller and can be tested with the new Resttemplate. In this little sample project is Spring 3 combined with JUnit 4, Maven, Hibernate 3.2, Jetty, [...]

]]> By: Java Spring 3 RESTful Web Service « MINSIKZZANG IN PARIS http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-171041 Java Spring 3 RESTful Web Service « MINSIKZZANG IN PARIS Tue, 19 Jan 2010 07:00:43 +0000 http://blog.springsource.com/?p=1469#comment-171041 [...] http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/ [...] [...] http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/ [...]

]]> By: Ken McCracken http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-170848 Ken McCracken Tue, 05 Jan 2010 14:58:22 +0000 http://blog.springsource.com/?p=1469#comment-170848 I was looking at http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/client/RestTemplate.html#RestTemplate() and wondering why the "default settings" are not documented. I know I can look in the source code to see which implementation is currently used, but am concerned since it isn't documented that it might change?? Is there any reason not to specify a concrete ClientHttpRequestFactory implmentation as default in the Javadocs? I was looking at http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/client/RestTemplate.html#RestTemplate() and wondering why the "default settings" are not documented. I know I can look in the source code to see which implementation is currently used, but am concerned since it isn't documented that it might change?? Is there any reason not to specify a concrete ClientHttpRequestFactory implmentation as default in the Javadocs?

]]> By: Grzegorz Błaszczyk http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-170577 Grzegorz Błaszczyk Sun, 20 Dec 2009 22:08:41 +0000 http://blog.springsource.com/?p=1469#comment-170577 I corrected the file for downloading and added maven-dependency-plugin for easier java process launching. I corrected the file for downloading and added maven-dependency-plugin for easier java process launching.

]]> By: Grzegorz Błaszczyk http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-170576 Grzegorz Błaszczyk Sun, 20 Dec 2009 22:01:03 +0000 http://blog.springsource.com/?p=1469#comment-170576 I tried to compile a project that you provided as an example but it did not compile (interface had unimplemented methods). So I corrected it and added maven-dependency-plugin to gather all dependencies and copy to one place (i.e. target/lib) so the start of a java process will be as smooth as possible. zip uploaded on filefactory: http://www.filefactory.com/file/a127bhd/n/spring3-resttemplate-20091220.zip link on the bottom of the page ;) I tried to compile a project that you provided as an example but it did not compile (interface had unimplemented methods). So I corrected it and added maven-dependency-plugin to gather all dependencies and copy to one place (i.e. target/lib) so the start of a java process will be as smooth as possible.

zip uploaded on filefactory:
http://www.filefactory.com/file/a127bhd/n/spring3-resttemplate-20091220.zip
link on the bottom of the page ;)

]]> By: Daggie.be | Devoxx 2009, day 2 http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-169566 Daggie.be | Devoxx 2009, day 2 Thu, 19 Nov 2009 20:47:29 +0000 http://blog.springsource.com/?p=1469#comment-169566 [...] Arjen presented a demo on REST support for retrieving images from Flickr, that can be found here. Spring 3.0 should be adrop-in replacement voor [...] [...] Arjen presented a demo on REST support for retrieving images from Flickr, that can be found here. Spring 3.0 should be adrop-in replacement voor [...]

]]> By: Siddhartha http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-168789 Siddhartha Tue, 13 Oct 2009 10:44:24 +0000 http://blog.springsource.com/?p=1469#comment-168789 Hi , The above is very helpful. I have a rest server in apache cxf with spring. I was looking for the list capture through rest template. I found the following code snippet is working well. Hopefully It would help others SecurityCredentialBean[] res =(SecurityCredentialBean[])this.restTemplate.getForObject(uri, SecurityCredentialBean[].class, vars); List securityCredentialBeans = Arrays.asList(res); Thanks --Siddhartha Hi ,

The above is very helpful.

I have a rest server in apache cxf with spring. I was looking for the list capture through rest template. I found the following code snippet is working well. Hopefully It would help others

SecurityCredentialBean[] res =(SecurityCredentialBean[])this.restTemplate.getForObject(uri, SecurityCredentialBean[].class, vars);
List securityCredentialBeans = Arrays.asList(res);

Thanks
–Siddhartha

]]> By: Marius Munteanu http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-168550 Marius Munteanu Sun, 27 Sep 2009 16:42:05 +0000 http://blog.springsource.com/?p=1469#comment-168550 Great work for 3.0! Unfortunately, the maven 3.0.0.* .pom files have weird dependencies configured such as: org.apache.commons com.springsource.org.apache.commons.logging or org.apache.log4j com.springsource.org.apache.log4j and many others... It looks like the artifcatId is worng on all the external dependencies. Am I missing something? P.S.: I am using the milestone repo SpringSource Enterprise Bundle Repositorys http://repository.springsource.com/maven/bundles/milestone Great work for 3.0!

Unfortunately, the maven 3.0.0.* .pom files have weird dependencies configured such as:
org.apache.commons
com.springsource.org.apache.commons.logging
or
org.apache.log4j
com.springsource.org.apache.log4j
and many others…

It looks like the artifcatId is worng on all the external dependencies.

Am I missing something?

P.S.: I am using the milestone repo

SpringSource Enterprise Bundle Repositorys
http://repository.springsource.com/maven/bundles/milestone

]]> By: Brian Topping http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-168522 Brian Topping Tue, 22 Sep 2009 14:34:12 +0000 http://blog.springsource.com/?p=1469#comment-168522 Oh, my bad, the third and possibly best option is creating a RequestCallback. It will be computationally the most expensive, but with the least (or no) impact to the current code. That way, you can have a stab at it and merge it into the code base as you are most comfortable with for long-term support. Oh, my bad, the third and possibly best option is creating a RequestCallback. It will be computationally the most expensive, but with the least (or no) impact to the current code. That way, you can have a stab at it and merge it into the code base as you are most comfortable with for long-term support.

]]> By: Brian Topping http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/comment-page-1/#comment-168521 Brian Topping Tue, 22 Sep 2009 14:16:33 +0000 http://blog.springsource.com/?p=1469#comment-168521 Hi Arjen, thanks for your response. No problem on the timing, there's always another version and this code is isolated enough that I can run my own version until it's integrated. A crash course on OAuth would be to say that the hierarchical part of the URI is left alone for signature purposes, but all the query attributes need to be sorted and a URL string generated before the hash is calculated. As well, in a form-based POST, the attributes of the form need to be included in that sort for the signature calculation. Two approaches come to mind: The first would be to rewrite UriTemplate such that it can add a signature in-place as a part of the variable expansion. This is complicated by the fact that the sort for the signature also requires any form variables that may exist plus the method (GET, POST, etc.) to calculate the hash. In this case, it probably makes sense to refactor the UriTemplate.expand() code to a client responsibility, sending in a final java.net.URI. This has the least impact to the existing code. The second approach would be to add authorization post-processing code to doExecute(). But in doing so, there is an efficiency cost since the query part of the URI needs to be re-parsed so it can be sorted. The advantage here is by the time the code is executed, we have all the form components and completed URI available to us, and in doing so, the existing functionality exposed to the client and managed by UriTemplate is unchanged. WDYT? Feel free to respond off-list to my email address. Hi Arjen, thanks for your response. No problem on the timing, there's always another version and this code is isolated enough that I can run my own version until it's integrated.

A crash course on OAuth would be to say that the hierarchical part of the URI is left alone for signature purposes, but all the query attributes need to be sorted and a URL string generated before the hash is calculated. As well, in a form-based POST, the attributes of the form need to be included in that sort for the signature calculation.

Two approaches come to mind: The first would be to rewrite UriTemplate such that it can add a signature in-place as a part of the variable expansion. This is complicated by the fact that the sort for the signature also requires any form variables that may exist plus the method (GET, POST, etc.) to calculate the hash. In this case, it probably makes sense to refactor the UriTemplate.expand() code to a client responsibility, sending in a final java.net.URI. This has the least impact to the existing code.

The second approach would be to add authorization post-processing code to doExecute(). But in doing so, there is an efficiency cost since the query part of the URI needs to be re-parsed so it can be sorted. The advantage here is by the time the code is executed, we have all the form components and completed URI available to us, and in doing so, the existing functionality exposed to the client and managed by UriTemplate is unchanged.

WDYT? Feel free to respond off-list to my email address.

]]>