Restful web services by Sreeni Inturi
3 likes1,891 views
The document discusses REST (REpresentational State Transfer), a style of architecture for building web services. It defines REST and RESTful web services, describes the key REST principles of using resources and uniform interfaces. It explains why REST is preferable to SOAP in many cases due to being lightweight, supporting multiple data formats and better performance. The document also provides guidance on when each approach is better suited and compares SOAP vs REST. It introduces JAX-RS as a Java API for building RESTful web services and some common implementations like Jersey.
Restful web services 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