Its hard to say anything about spring without seeming biased in favor. Spring's RestTemplate is as solid as can be expected. Their standard call back based approach for safe release of resources works well even for the REST template. If one is using Spring-mvc and their REST support, very few reasons would drive me to consider an alternative framework for the client. One among them is definitely finer grained control, another is Http Client 4.X support. Documentation is sparse on RestTemplate as well. But one has a community to back up on. There might a bit of up front customizations, standard call back etc that an adopter might create but once done I feel that it would be a easy to work with the RestTemplate.
Clearly one has many choices in selecting a client side framework for RESTful HTTP. In most cases it probably makes sense to use the same framework for the service and client end. Then again, if you are only a consumer of a service you have multiple choices among those shown above as well as the option of using Apache HTTP Client or Components directly and bypassing the higher level frameworks. For some, integrating with the spring framework is important and all the above frameworks have means of integration points, both on the service and client sides. Support for Client Proxies is something one might want to consider as they tend to simplify the programming model. Further if Resource definitions can be shared among client server, that can be quite useful in being DRY (Don't repeat yourself) and provide means for contract definition. For those interested in performance and tuning of the HTTP Connections, using a framework that allows you to manage connection pooling and other parameters is definitely the way to go.
For more information on Spring RestTemplate, visit Spring blog
Spring RestTemplate Example:
Showing posts with label REST. Show all posts
Showing posts with label REST. Show all posts
Thursday, August 12, 2010
Friday, July 23, 2010
JERSEY
Sun offers a reference implementation for JAX-RS code-named Jersey. Jersey uses a HTTP web server called Grizzly, and the Servlet Grizzly Servlet (com.sun.jersey.spi.container.servlet.ServletContainer) handles the requests to Grizzly. You can develop production-quality JAX-RS applications today using Jersey, which implements all the APIs and provides all the necessary annotations for creating RESTful web services in Java quickly and easily. Beyond the set of annotations and features defined by JAX-RS, Jersey provides additional features through its own APIs, such as the Jersey Client API.
You can download Jersey separately or acquire it as a bundle with NetBeans 6.5 and GlassFish V3.
Developing RESTful Web Services Using JAX-RS
The classes and interfaces you use for creating RESTful web services with JAX-RS are available in the following packages:
javax.ws.rs
javax.ws.rs.core
javax.ws.rs.ext
I'm going to provide link to previous post for Jersey example and will write about Sprint rest template in my next post...
Jersey Example
You can download Jersey separately or acquire it as a bundle with NetBeans 6.5 and GlassFish V3.
Developing RESTful Web Services Using JAX-RS
The classes and interfaces you use for creating RESTful web services with JAX-RS are available in the following packages:
javax.ws.rs
javax.ws.rs.core
javax.ws.rs.ext
I'm going to provide link to previous post for Jersey example and will write about Sprint rest template in my next post...
Jersey Example
Sunday, July 11, 2010
REST Framework implementation
I'm going to write a series of framework that can be used for REST implementation. I have looked different JAX RS vendors such as Jersey, RESTEasy and Restlet JAX-RS. but if you look at client side support, the JAX RS specification does not include a client side API and different JAX RS vendors have proceeded to create their own API's for the same. which means the framework one selects for the client and service ends do not have to be the same. For example, one could have a RESTful service running using Restlet while having a client developed in RESTEasy that consumes the same. In most cases, one will typically be satisfied with using the same client framework as one is using for the service development in order to be consistent and potentially be able to re-use artifacts in both areas if the framework permits the same. i have listed few options take a look at them.
Jersey - A JAX RS reference implementation from Oracle/Sun.
Spring 3.0 - Spring provides a RestTemplate, quite like the JmsTemplate and HibernateTemplate in its support of REST clients.
CXF - An apache project that is a merger of XFire and Celtix. Provides a JAX RS implementation and JAX WS as well.
RESTEasy - A JAX RS reference implementation by JBoss.
Restlet - A new upcoming framework that has support for Client Side REST calls
Apache Wink - A JAX RS implementation that has a client and server side api that has had a 1.0 release just recently
Apache HTTPClient or Http Components - Direct use of HTTP API - Down and dirty.
Im my next post i'll be talking about JERSEY and might present small example of that.
Jersey - A JAX RS reference implementation from Oracle/Sun.
Spring 3.0 - Spring provides a RestTemplate, quite like the JmsTemplate and HibernateTemplate in its support of REST clients.
CXF - An apache project that is a merger of XFire and Celtix. Provides a JAX RS implementation and JAX WS as well.
RESTEasy - A JAX RS reference implementation by JBoss.
Restlet - A new upcoming framework that has support for Client Side REST calls
Apache Wink - A JAX RS implementation that has a client and server side api that has had a 1.0 release just recently
Apache HTTPClient or Http Components - Direct use of HTTP API - Down and dirty.
Im my next post i'll be talking about JERSEY and might present small example of that.
Saturday, March 27, 2010
What are RESTful Web Services?
A paper that expands on the basic principles of REST technology can be found at:
http://www2008.org/papers/pdf/p805-pautassoA.pdf
The REST architectural style is based on four principles:
Resource identification through URI.
A RESTful Web service exposes a set of resources which identify the targets of the interac- tion with its clients. Resources are identified by URIs [5], which provide a global addressing space for resource and service discov- ery.
Uniform interface.
Resources are manipulated using a fixed set of four create, read, update, delete operations: PUT, GET, POST, and DELETE. PUT creates a new resource, which can be then de- leted using DELETE. GET retrieves the current state of a resource in some representation. POST transfers a new state onto a resource.
Self-descriptive messages.
Resources are decoupled from their representation so that their content can be accessed in a variety of formats (e.g., HTML, XML, plain text, PDF, JPEG, etc.). Meta- data about the resource is available and used, for example, to con- trol caching, detect transmission errors, negotiate the appropriate representation format, and perform authentication or access con- trol.
Stateful interactions through hyperlinks.
Every interaction with a resource is stateless, i.e., request messages are self-contained. Stateful interactions are based on the concept of explicit state trans- fer. Several techniques exist to exchange state, e.g., URI rewriting, cookies, and hidden form fields. State can be embedded in response messages to point to valid future states of the interaction.
http://www2008.org/papers/pdf/p805-pautassoA.pdf
The REST architectural style is based on four principles:
Resource identification through URI.
A RESTful Web service exposes a set of resources which identify the targets of the interac- tion with its clients. Resources are identified by URIs [5], which provide a global addressing space for resource and service discov- ery.
Uniform interface.
Resources are manipulated using a fixed set of four create, read, update, delete operations: PUT, GET, POST, and DELETE. PUT creates a new resource, which can be then de- leted using DELETE. GET retrieves the current state of a resource in some representation. POST transfers a new state onto a resource.
Self-descriptive messages.
Resources are decoupled from their representation so that their content can be accessed in a variety of formats (e.g., HTML, XML, plain text, PDF, JPEG, etc.). Meta- data about the resource is available and used, for example, to con- trol caching, detect transmission errors, negotiate the appropriate representation format, and perform authentication or access con- trol.
Stateful interactions through hyperlinks.
Every interaction with a resource is stateless, i.e., request messages are self-contained. Stateful interactions are based on the concept of explicit state trans- fer. Several techniques exist to exchange state, e.g., URI rewriting, cookies, and hidden form fields. State can be embedded in response messages to point to valid future states of the interaction.
Subscribe to:
Posts (Atom)