REST-style architectures consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of "representations" of "resources". A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.

At any particular time, a client can either be in transition between application states or "at rest". A client in a rest state is able to interact with its user, but creates no load and does not consume per-client storage on the set of servers or on the network.

The client begins sending requests when they are ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition. The representation of each application state contains links that may be used next time the client chooses to initiate a new state transition.

REST was initially described in the context of HTTP. However, it is not limited to that protocol. RESTful architectures can be based on other Application Layer protocols if they already provide a rich and uniform vocabulary for applications based on the transfer of meaningful representational state. RESTful applications maximize the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimize the addition of new application-specific features on top of it.

The recent rapid advancements and adoption of web services, Service-Oriented Architecture (SOA), and Representational State Transfer architectures within enterprises have left the industry wanting more. Organizations and developers, such as those who focus on Web 2.0, are demanding interface support from identity and access management software. In this chapter, let us focus on some of the RESTful features provided by the OpenSSO server, including the following:

You can obtain the list of web services end points provided by the OpenSSO server by entering the following URL: http://opensso.packt-services.net:9090/opensso/identityservices. Assuming that you have set up the OpenSSO at this URL, for the sake of clarity, in the succeeding examples this URL will be quoted.

Alternatively, to view the WSDL for the supported methods point your browser at http://opensso.packt-services.net:9090/opensso/identityservices/IdentityServices?WSDL.

In the next several sections you will be shown how the REST-based interfaces can be invoked for various supported methods. I will be using the curl utility for ease of use and brevity to make the point clear. Besides, the commands can simply be cut and pasted from the book onto your terminal to expedite your learning process. Remember the same thing can be achieved via a browser or other programs such as a PHP script. There are about 11 REST operations that are exposed in the OpenSSO server. These operations are supported out of the box configuration of OpenSSO; there are no special configurations required. The screenshot we are about to see illustrates those operations. You can find more detailed account on this subject in the article http://developers.sun.com/identity/reference/techart/id-svcs.html.

Prerequisites

The only prerequisite is to deploy and configure the OpenSSO web application on a supported container such as Apache Tomcat. For this exercise, I have deployed the server on Apache Tomcat 6.0.20 and leveraged the embedded identity data store to perform these simple operations. If you would like to work on the role IDtype, then you must use a supported identity data store such as the Oracle Directory Server Enterprise Edition.

Another key thing here, as mentioned earlier, is that I would like to use the curl utility. It supports both GET/POST methods, and so easily shows the input and output parameters, to verify these REST operations.