Jersey (1.19.1)-Uniform Interface Constraint

The Jersey client API is a high-level Java based API for interoperating with RESTful Web services. It makes it very easy-to-interoperate with RESTful WEB services and enables a developer to concisely and efficiently imple ment A reusable client-side solution that leverages existing and well established Client-side HTTP implementations.

The Jersey client API can be utilized to interoperate with any RESTful WEB service, implemented using one of many Framewor KS, and is not a restricted to services implemented using JAX-RS. However, developers familiar with Jax-rs should find the Jersey client API complementary to their services, especially if The client API is utilized by those services themselves, or to test those services.

The goals of the Jersey client API is threefold:

1. Encapsulate a key constraint of the REST architectural style, namely the Uniform Interface constraint and associated data Elements, as client-side Java artifacts;
2. Make it as easy-to-interoperate with restful Web services as Jax-rs makes it easy to build RESTful Web services; and
3. Leverage artifacts of the Jax-rs API for the client side. Note that Jax-rs are currently a server-side only API.

The Jersey client API supports a pluggable architecture to enable the use of different underlying HTTP Client Implementati Ons. The such implementations is supported and leveraged:the Http(s)URLConnection classes supplied with the JDK, and the Apache HTTP client.

The Uniform interface constraint bounds the architecture of RESTful WEB services so that a client, such as a browser, can Utilize the same interface to communicate with any service. This was a very powerful concept in software engineering that makes web-based search engines and service mash-ups possible. It induces properties such as:

1. Simplicity, the architecture is easier to understand and maintain; and
2. Modifiability or loose coupling, clients and services can evolve over time perhaps in new and unexpected ways, while Retai Ning backwards compatibility.

Further constraints is required:

1. Every resource is identified by a URI;
2. A client interacts with the resource via HTTP requests and responses using a fixed set of HTTP methods;
3. One or more representations can retured and is identified by media types; and
4. The contents of which can link to further resources.

The above process repeated over and again should is familiar to anyone who have used a browser to fill in HTML forms and fo Llow links. That same process was applicable to Non-browser based clients.

Many existing java-based client APIs, such as the Apache HTTP client API or java.net.HttpURLConnection supplied with the JDK place too much FOC US on the client-server constraint for the exchanges of request and responses rather than a resource, identified by a URI, And the use of a fixed set of HTTP methods.

A resource in the Jersey client API was an instance of the Java class WebResource, and encapsulates a URI. The fixed set of HTTP methods is methods on WebResource or if using the "builder" pattern (more in this later) is the last Metho DS to is called when invoking an HTTP method on a resource. The representations is Java types, instances of which, may contain links that new instances of May is WebResource created from.

Jersey (1.19.1)-Uniform Interface Constraint