RESTful Web services are the latest revolution in the development of Web applications and distributed programming for integrating a great number of enterprise applications running on different platforms. Representational state transfer (REST) is the architectural principle for defining and addressing Web resources without using the heavy SOAP stack of protocols (WS-* stack). From the REST perspective, every Web application is a service; thus it's very easy to develop Web services with basic Web technologies such as HTTP, the URI naming standard, and XML and JSON parsers. (The story of RESTful Web services begins with Chapter 5 of Roy Fielding's Ph.D. dissertation, Architectural Styles and the Design of Network-Based Software Architecture, although Fielding, one of the authors of the HTTP spec, presents REST not as a reference architecture but as an approach to judging distributed architectures.)

The key to RESTful Web services is that application state and functionality are abstracted as resources on the server side. These resources are uniquely referenced by global identifiers via URI naming, and they share a uniform interface for communication with the client, consisting of a set of well-defined operations and content types. The traditional HTTP methods—POST, GET, PUT, and DELETE (also known as verbs in REST terminology)—encompass every create, read, update, and delete (CRUD) operation that can be performed on a piece of data. The GET method is used to perform a read operation that returns the contents of the resource. The POST method is used to create a resource on the server and assign a reference to this resource. The PUT method updates the resources when the client submits content to the server. And finally, the DELETE method is used to delete a resource from the server.

URI naming must be meaningful and well structured, so the clients can go directly to any state of the application through resource URIs without passing by intermediate layers. It's recommended to use path variables to separate the elements of the path in a hierarchical way. For example, to get a list of customers, the URI can be http://server/customers, and to get the customer whose identifier is 1234, the URI can be http://server/customers/1234. You must use punctuation characters to separate multiple pieces of data at the same level in the hierarchy. For example, to get customers whose identifiers are 1234 and 5678, the URI can be http://server/customers/1234;5678, with a semicolon separating the identifiers. The last tip is to use query variables to name parameters—URI naming is for designating resources, not operations, so it's not appropriate to put operation names in the URI. For example, if you want to delete the customer 1234, you should avoid the URI http://server/deletecustomers/1234; the solution is to overload the HTTP methods (POST, PUT, and DELETE).

The data exchanged across resources can be represented with MIME types such as XML or JSON documents as well as images, plain texts, or other content formats. This is specified via the Content-Type header in the requests. The format used in the application will depend on your requirements. If you want to convey structured data, the format might be XML, YAML, JSON, or CSV. If you want to transfer documents, you might use a format such as HTML, DocBook, SGML, ODF, PDF, or PostScript. You can also deal with different content for manipulating photos (JPG, PNG, BMP), calendar information (iCal), and categorized links (OPML).

And finally, RESTful Web services need protocols to transfer states that must be client/server, stateless, cacheable, and layered, so there can be any number of connectors (client, servers, caches, tunnels, firewalls, gateways, routers) that transparently mediate the request.

There are two types of states in RESTful Web services: resource and application. The resource state is information about resources, stays on the server side, and is sent to the client only in the form of representation. The application state is information about the path the client has taken through the application, and it stays on the client side until it can be used to create, modify, and delete resources.

A RESTful Web service is by nature stateless, and if the client wants the states to take part of the request, then it must be submitted as part of the underlying request. Statelessness is a very important feature for supporting scalability in your solution, because no information is stored on the server (this is responsibilities of the client) and none of it is implied from previous requests. If you have a workload balancer and a request cannot be handled by one server, another one can process this request, because message requests are self-contained, and we don't need to refactor the solution architecture.

Ruby on Rails is an open source Web development framework for the Ruby programming language. You can create a Web application very easily to expose relational data, using REST principles. Django, another open source Web development framework, was written for the Python programming language, following the model-view-controller (MVC) design pattern.

And finally, for Java developers, JAX-RS (JSR 311) provides an API for creating RESTful Web services according to REST principles. JAX-RS uses annotations (Java 5 and above) to simplify the development effort for Web services artifacts, so you can expose simple Plain Old Java Objects (POJOs) as Web resources. There are several JAX-RS-based implementations, such as Jersey, JBoss RESTEasy, Restlet, Apache CXF, and Triaxrs. This article explains how to develop REST Web services by using the Jersey framework (the Sun reference implementation for JAX-RS) and Oracle JDeveloper 11g. (At the time of this writing, Oracle is planning to support JAX-RS in the near future by using the Jersey framework approach, integrated with Oracle JDeveloper tools and Oracle WebLogic Server.)

To set up the environment to develop the RESTful Web service with the Jersey framework, download the Jersey libraries with all the necessary dependencies from https://jersey.dev.java.net/. After you reach this site, you can see that Jersey contains several major parts:

* Core server. A set of annotations and APIs (standardized in JSR-311) to develop a RESTful Web service
* Core client. The client API for communicating with REST services
* Integration. A set of libraries for integrating Jersey with Spring, Guice, Apache Abdera, and so on

Full article...