By Sreeni Inturi

1.  What is REST?
 What is the RESTful Web Service?
 What are the REST principles?
 Why REST?
 Why SOAP?
 When to use REST?
 When to use SOAP?
 SOAP vs REST
 JAX-RS
 Set up , develop and run in Eclipse and Tomcat / JBOSS
 References

2. Whati R EST:
s
• REST - REpresentational State Transfer (REST), an
architectural style for accessing information on the
web, has made it a popular way for developers to
access services.
• In the REST architectural style, information on the
server side is considered a resource, which developers
can access in a uniform way using web URIs (Uniform
Resource Identifiers) and HTTP.
• REST uses HTTP as the communication protocol, the
REST style is constrained to a stateless client/server
architecture.
• REST is light weight and an alternative to SOAP,WSDL
Web services.

3. Whati R ESTfulW ebS erv ce?
s i
• RESTful web services (i.e., web services that are created
and accessed using REST principles) use HTTP protocol
methods for the operations they perform.
• For example, a developer can map the HTTP methods
POST, GET, PUT, and DELETE to create, read, update and
delete (CRUD) operations.

4. REST Principles:
 REST isn't protocol specific.
 Technologies like SOAP use HTTP strictly as a transport
protocol and thus use a very small subset of its capabilities. WS-
* uses HTTP solely to tunnel through firewalls.
 HTTP is actually a very rich application protocol which gives us
things like content negotiation and distributed caching.
RESTful web services try to leverage HTTP in its entirety using
specific architectural principles.
 Key REST principles:
 Everything is a resource.
 Every resource is identified by a unique identifier.
 Use simple and uniform interfaces.
 Communication are done by representation.
 Be Stateless.

5. REST Principles cont..
 Addressable Resources. Every “thing” on your network
should have an ID. With REST over HTTP, every object
will have its own specific URI.
 A Uniform, Constrained Interface. When applying
REST over HTTP, stick to the methods provided by the
protocol. This means following the meaning of GET,
POST, PUT, and DELETE religiously.
 Representation oriented. You interact with services
using representations of that service. An object
referenced by one URI can have different formats
available. Different platforms need different formats.
AJAX may need JSON. A Java application may need
XML.
 Communicate statelessly. Stateless applications are
easier to scale.

6. Why REST?
 Since REST uses standard HTTP it is much simpler in
just about ever way. Creating clients, developing APIs,
the documentation is much easier to understand .
 REST permits many different data formats whereas
SOAP only permits XML. While this may seem like it
adds complexity to REST because you need to handle
multiple formats. but it has actually been quite
beneficial. JSON usually is a better fit for data and
parses much faster. REST allows better support for
browser clients due to it’s support for JSON.
 REST has better performance and scalability. REST
reads can be cached, SOAP based reads cannot be
cached.

7. Why SOAP?
 Here are a few reasons you may want to use SOAP.
 WS-Security
 While SOAP supports SSL (just like REST) it also supports WS-
Security which adds some enterprise security features. Supports
identity through intermediaries, not just point to point (SSL). It
also provides a standard implementation of data integrity and data
privacy.
 WS-Atomic Transaction
 Need ACID Transactions over a service, you’re going to need SOAP.
While REST supports transactions, it isn’t as comprehensive and
isn’t ACID compliant. Fortunately ACID transactions almost never
make sense over the internet. REST is limited by HTTP itself which
can’t provide two-phase commit across distributed transactional
resources, but SOAP can.
 WS-Reliable Messaging
 Rest doesn’t have a standard messaging system and expects clients
to deal with communication failures by retrying. SOAP has
successful/retry logic built in and provides end-to-end reliability
even through SOAP intermediaries.

8. When to use REST?
 Architects and developers need to decide when this particular style is an
appropriate choice for their applications. A RESTFul design may be
appropriate when
 The web services are completely stateless.
 A caching infrastructure can be leveraged for performance. If
the data that the web service returns is not dynamically
generated and can be cached,it leveraged to improve
performance.
 The service producer and service consumer have a mutual
understanding of the context and content being passed along.
Because there is no formal way to describe the web services
interface
 Bandwidth is particularly important and needs to be limited.
REST is particularly useful for limited-profile devices such as
PDAs and mobile phones, for which the overhead of headers
and additional layers of SOAP elements on the XML payload
must be restricted.

9. When to use SOAP?
 SOAP is fairly mature and well-defined and does come with
a complete specification. The REST approach is just that,
an approach and is wide open for development, so if you
have the following then SOAP is a great solution:
 Asynchronous processing and invocation: if your
application needs a guaranteed level of reliability and
security then SOAP 1.2 offers additional standards to
ensure this type of operation. Things like WSRM – WS-
Reliable Messaging.
 Formal contracts: if both sides (provider and consumer)
have to agree on the exchange format then SOAP 1.2 gives
the rigid specifications for this type of interaction.
 Stateful operations: if the application needs contextual
information and conversational state management then
SOAP 1.2 has the additional specification in the WS*
structure to support those things (Security, Transactions,
Coordination, etc). Comparatively, the REST approach
would make the developers build this custom plumbing.

10. SOAP vs REST:
 SOAP stands for Simple Object Access Protocol. REST
stands for REpresentational State Transfer.
 SOAP is a XML based messaging protocol and REST is not
a protocol but an architectural style.
 SOAP has a standard specification but there is none for
REST.
 Whole of the web works based on REST style architecture.
Consider a shared resource repository and consumers
access the resources.
 Even SOAP based web services can be implemented in
RESTful style. REST is a concept that does not tie with any
protocols.
 SOAP is distributed computing style and REST is web style
(web is also a distributed computing model).

11. SOAP vs REST cont..
 REST messages should be self-contained and should help
consumer in controlling the interaction between provider and
consumer(example, links in message to decide the next course
of action). But SOAP doesn’t has any such requirements.
 REST does not enforces message format as XML or JSON or etc.
But SOAP is XML based message protocol.
 REST follows stateless model. SOAP has specifications for
stateful implementation as well.
 SOAP is strongly typed, has strict specification for every part of
implementation. But REST gives the concept and less
restrictive about the implementation.
 Therefore REST based implementation is simple compared to
SOAP and consumer understanding.

12. SOAP vs REST cont..
 SOAP uses interfaces and named operations to expose
business logic. REST uses (generally) URI and
methods like (GET, PUT, POST, DELETE) to expose
resources.
 SOAP has a set of standard specifications. WS-Security
is the specification for security in the implementation.
It is a detailed standard providing rules for security in
application implementation. Like this we have
separate specifications for messaging, transactions,
etc. Unlike SOAP, REST does not has dedicated
concepts for each of these. REST predominantly relies
on HTTPS.
 Above all both SOAP and REST depends on design and
implementation of the application.

13. JAX- RS (Java API for Restful Web Services) :
 JAX –RS (JSR 311) provides an API for creating RESTful web
services in Java.
 Part of the Java EE 6 platform, JAX-RS fully supports REST
principles.
 The JAX-RS API uses annotations to simplify the development
of RESTful web services.
 Annotations, along with the classes and interfaces provided by
JAX-RS API, allow you to expose simple POJOs as web
resources. Because of its heavy reliance on annotations, JAX-RS
requires Java 5 and above.
 Like other Java web applications, you bundle JAX-RS
applications as a WAR file and deploy them on a container that
supports Servlets.

14. JAX-RS cont..
Different Implementations for JAX-RS:
 Jersey - Sun (Oracle) reference implementation.
 RESTEasy - JBoss's implementation.
 Apache CXF - an open source Web service framework.
 Restlet - REST frameworks.
Different clients in Java for Restful web service:
 Apache HtppClient
 Jersey Client
 RESTEasy Client
 Java.net.URL

15. Jersey : JAX-RS RI
 A goal of JAX-RS is to enable the portability to deploy web
resources across different types of web containers.
 Sun(Oracle) 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.

16. Se up, developa ndt e tR e t webs erv ce i n
t s s i s
ecl s e,a ndt omc t:
ip a
 Down load jersey project (jave.net) zip file and get jars
files.
 Create web project in eclipse (Java 1.5 and above) and
add above jar files in class path.
 Add Tomcat or JBoss server to this project.
 Add jersey servlet info in web-xml
 Create java class and covert to Resource using
annotations(@Path, @GET, @Produces etc.)
 Run project on server and in browser use base URI to
test this.
 Write Client class using Apache HttpClient or Jersey
client by using rest endpoint and consume it.

17. JAX-RS Resource..
 The Resource Class
 JAX-RS defines a resource as any Java class (POJO) that uses JAX-RS annotations to
implement a web resource. The annotation @Path identifies a Java class as a resource
class. Here is an example:
 import javax.ws.rs.Path;
 @Path("/stockquote")
 public class StockResource {
 .......
 public String getStockInfo() {
 return "This is Stock Information";
 } }

 A new instance of the resource class will be created for each request to that resource.
After the object creation, the constructor is invoked, the required dependencies are
injected, the appropriate resource method is invoked, and when the response is provided,
the object is made available for garbage collection. Following the Resource class lifecycle.

18. Resouce cont..
 Resource Methods
 Resource methods are public methods of a resource class that you identify with a request method
designator. Request method designators are annotations that you use to identify the methods that
handle the HTTP requests, and JAX-RS defines annotations for HTTP methods such as GET, POST,
PUT, DELETE, and HEAD. JAX-RS also allows you to create user-defined custom request method
designators.
 JAX-RS provides a clear mapping between the HTTP protocol and the URIs through well-defined
classes and interfaces. RESTful web services, the HTTP methods are mapped to the CRUD operations
they perform.
 HTTP method request dictates which request method designator is called. For example, if the request
is from a HTTP GET request, the service automatically invokes a method annotated with @GET and
provides the response.

 Return value of a resource method could be void, a response object, or any other Java type. For HTTP
requests, you use the JAX-RS API's MessageBodyReader class to map the request entity body to
method parameters. Similarly, for HTTP responses, you use MessageBodyWriter to map a return value
to the response entity body. These classes take care of the conversion between the Java types and
entity bodies. Resource methods can also throw any checked or unchecked exception.

19. References:
 http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_
Services
 http://jax-rs-spec.java.net/
 http://en.wikipedia.org/wiki/Resource-
oriented_computing
 http://www.oracle.com/technetwork/articles/javase/index-
137171.html
 http://www.ibm.com/developerworks/webservices/library/
ws-restful/
 http://cxf.apache.org/docs/jax-rs.html
 http://www.jboss.org/resteasy/
 http://www.ics.uci.edu/~taylor/documents/2002-REST-
TOIT.pdf