Jersey Client Side: The ViewResource Class

The last posting in this introductory series provided a high level overview of the Jersey client side framework I am working on together with Paul. In this one, we look at some of the details.

At the heart of the framework lies the concept of ViewResources. Conceptually, ViewResources are an extension of the existing Jersey client side WebResource class. A ViewResource is a client side ‘handle’ for an HTTP resource through which HTTP requests to the resource can be performed. While WebResource ‘invocations’ result in ClientResponses or object representations of the response entities ‘invocations’ of ViewResources produce view objects that encapsulate assumptions (including anticipated next transitions).

The choice of view class for a given request completely expresses the assumptions made about the resource and the response. The view class in turn encapsulates these assumptions in a single artifact.

Regarding the examples that follow it is important to keep in mind that the view objects are not to be seen as local proxies for remote ‘objects’ but that the view objects hold application state and provide access to the data contained and a means to activate the controls that are (maybe) embedded in it.

In a subsequent installment of this introductory series we will see how even the entities of error responses constitute application state and can be used to construct corresponding views (possibly with contained application data and/or embedded controls for outgoing state transitions).

GET requests

URI poUri = URI.create("http://foo.org/purchaseOrders/42");
ViewResource vr = client.viewResource(poUri);
PurchaseOrderView pov = vr.get(PurchaseOrderView.class);

For GET requests there is a shorthand removing the need for an intermediate ViewResource object:

URI poUri = URI.create("http://foo.org/purchaseOrders/42");
PurchaseOrderView pov = client.view(poUri,PurchaseOrderView.class);

PUT requests

URI poUri = URI.create("http://foo.org/purchaseOrders/42");
ViewResource vr = client.viewResource(poUri);
PurchaseOrderView pov = vr.put(PurchaseOrderView.class, "some purchase order data");

For the use with PUT requests the build method of the PurchaseOrderView class could be implemented to work with both 200 Ok and 204 No Content responses. In the former case the body woud be interpreted as a representation of the order and in the latter the build method could perform an additional GET on the request URI to obtain a a representation of the order. We will discuss such support for automated transitions in a dedicated posting.

POST requests

URI colUri = URI.create("http://foo.org/purchaseOrders");
ViewResource vr = client.viewResource(colUri);
CreatedView<PurchaseOrderView> cv = new CreatedView(PurchaseOrderView.class);
vr.post(cv, "some purchase order data");
PurchaseOrderView newPoView = cv.getCreated();

This example makes use of the ‘helper’ view class CreatedView<T> provided with the framework. This view class encapsulates the HTTP mechanics related to 201 Created responses and makes the created resource retrievable as a view through the getCreated() method.

Note how this example instantiates the view class outside the framework and supplies the instance directly to the post() invocation.

DELETE requests

URI poUri = URI.create("http://foo.org/purchaseOrders/42");
ViewResource vr = client.viewResource(poUri);
VoidView vv = vr.delete(VoidView.class);

This example uses the framework supplied view class VoidView to handle the (possible empty) response to the DELETE request. Because the VoidView really does not express any kind of expectation its use outside the context of pure examples is rather useless.

Expectations pertaining to the context of a request should be encapsulated inside a view class and not be propagated into the code that actually uses the view. Deal with HTTP mechanics (such as checking response status) inside view classes.

2 Responses to “Jersey Client Side: The ViewResource Class”

  1. [...] Jersey Client Side: The ViewResource Class [...]

  2. [...] RESTful Client Side Framework for Jersey and Jersey Client Side: The ViewResource Class – Two introductory posts about a new “client side framework for Jersey that [...]

Leave a Reply