Java | Rest

Java

Rest
pg. 1
 Java | Rest

Introduction
REST is not an architecture; rather, it is a set of constraints that creates a
software architectural style, which can be used for building distributed applications.
A major challenge to the distributed applications is attributed to the diversity of
systems in an enterprise offering silos of business information.
Table 1. Putting REST in Context

Question Answer
What are they? REST is used to build Web services that are lightweight,
maintainable, and scalable in nature. A service which is built on
the REST architecture is called a RESTful service. The underlying
protocol for REST is HTTP, which is the basic web protocol. REST
stands for REpresentational State Transfer.
Why are they useful? It enables web applications that are built on various
programming languages to communicate with each other. With
the help of Restful services, these web applications can reside
on different environments, some could be on Windows, and
others could be on Linux.
How are they used? JAX-RS specification provides set of APIs to create Restful web
services. There are many tools and frameworks available in the
market today for building RESTful web services.
Are there any pitfalls or RESTful Web service support is available only for Web service
limitations? applications with literal operations.
Are there any alternatives? You can work with JAX-WS framework(SOAP) create services
but SOAP supports only POST request and doesn’t support
different types of message formats.

The main idea behind REST is that a distributed system, organized RESTfully,
will improve in the following areas:
Table 2. REST improvements

Area Description
Performance The communication style proposed by REST is meant to be
efficient and simple, allowing a performance boost on systems
that adopt it.
pg. 2
 Java | Rest

Scalability of component Any distributed system should be able to handle this aspect well
interaction enough, and the simple interaction proposed by REST greatly
allows for this.
Simplicity of interface A simple interface allows for simpler interactions between
systems, which in turn can grant benefits like the ones
previously mentioned.
Modifiability of The distributed nature of the system, and the separation of
components concerns proposed by REST (more on this in a bit), allows for
components to be modified independently of each other at a
minimum cost and risk.
Portability & Visibility REST is technology- and language-agnostic, meaning that it can
be implemented and consumed by any type of technology
(there are some constraints that I’ll go over in a bit, but no
specific technology is enforced).
A system designed with REST in mind will be accessible to a
wider audience, thanks to its portability.
Reliability The stateless constraint proposed by REST (more on this later)
allows for the easier recovery of a system after failure.

SOAP vs REST
A comparsion between SOAP and REST with an example of use cases each can
support.
Table 3. SOAP vs REST

Topic SOAP REST

Basic Concept Makes data available as services (verb Makes data available as
+ noun), for example “getUser” or resources (nouns), for
“PayInvoice” example “user” or “invoice”
Pros  Follows a formal enterprise  Follows the philosophy of
approach the Open Web
 Works on top of any  Relatively easy to
communication protocol, even implement and maintain
asynchronously  Clearly separates client and
server implementations
pg. 3
 Java | Rest

 Information about objects is  Communication isn’t

communicated to clients controlled by a single entity
 Security and authorization are part  Information can be stored
of the protocol by the client to prevent
 Can be fully described using WSDL multiple calls.
 Can return data in multiple
formats (JSON, XML etc.)
Cons  Spends a lot of bandwidth  Only works on top of the
communicating metadata HTTP protocol
 Hard to implement and is  Hard to enforce
unpopular among Web and mobile authorization and security
developers on top of it

When to use  When clients need to have access  When clients and servers
to objects available on servers operate on a Web
environment
 When you want to enforce a formal
contract between client and server  When information about
objects doesn’t need to be
communicated to the client
When not to use  When you want the majority of  When you need to enforce
developers to easily use your API a strict contract between
 When your bandwidth is very client and server
limited  When performing
transactions that involve
multiple calls
Use cases  Financial services  Social media services
 Payment gateways  Social networks
 Telecommunication services  Web chat services
 Mobile services
Conclusion Use SOAP if you are dealing with Use REST if you’re focused on
transactional operations and you wide-scale API adoption or if
already have an audience that is your API is targeted at mobile
satisfied with this technology. apps.

Web Architectural Style

According to Fielding, there are two ways to define a system.
pg. 4
 Java | Rest

1. One is to start from a blank slate—an empty whiteboard—with no initial

knowledge of the system being built or the use of familiar components
until the needs are satisfied.
2. A second approach is to start with the full set of needs for the system, and
constraints are added to individual components until the forces that
influence the system are able to interact in harmony with each other.
REST follows the second approach. In order to define a REST architecture, a null-
state is initially defined—a system that has no constraints whatsoever and where
component differentiation is nothing but a myth—and constraints are added one by
one. The following subsections cover web architectural style constraints. Each of
these constrations defines how the framework for REST APIs should be architected
and designed.
Table 4. Constraints that define a RESTful system

Constraint Description
Client-Server This constraint keeps the client and server loosely coupled. In
this case, the client does not need to know the implementation
details in the server, and the server is not worried about how
the data is used by the client. However, a common interface is
maintained between the client and server to ease
communication.
Stateless There should be no need for the service to keep user sessions.
In other words, each request should be independent of the
others. This improves scalability, as the server does not need to
manage the state across multiple requests, with some trade-off
on the network performance.
Cacheable This constraint has to support a caching system. The network
infrastructure should support a cache at different levels.
Caching can avoid repeated round trips between the client and
the server for retrieving the same resource.
Uniform interface This constraint indicates a generic interface to manage all the
interactions between the client and server in a unified way,
which simplifies and decouples the architecture. This constraint
indicates that each resource exposed for use by the client must

pg. 5
 Java | Rest
have a unique address and should be accessible through a
generic interface. The client can act on the resources by using a
generic set of methods.
Layered system The server can have multiple layers for implementation. This
layered architecture helps to improve scalability by enabling
load balancing. It also improves the performance by providing
shared caches at different levels. Being the door to the system,
the top layer can enforce security policies as well.
Code on demand This constraint is optional. This constraint indicates that the
functionality of the client applications can be extended at
runtime by allowing a code download from the server and
executing the code. Some examples are the applets and the
JavaScript code that get transferred and executed at the client
side at runtime.

Table 5. Constraint and system property in context

By following the constraint Gain the following system property

Client-server interactions Simple, Evolvable, Scalable
Stateless communications Simple, Visible, Maintainable, Evolvable, and Reliable
Cacheable data Visible, Scalable, and Performant
Uniform Interfaces Simple, Usable, Visible, Accessible, Evolvable, and Reliable
Layered system Flexible, Scalable, Reliable, and Per formant
Code on demand Evolvable

The core architectural elements of a RESTful system

Analogous to any software architecture, the REST architecture is also defined
by a configuration of key architectural elements (components, connectors, and
data) with a set of constraints.
1. Data Elements
 The central feature that distinguishes the REST architectural style from other
network-based styles is its emphasis on a uniform interface between
components, which abstracts the information being transmitted.
pg. 6
 Java | Rest

 A uniform interface is fundamental to the architecture of any RESTful system.

In plain words, this term refers to a generic interface to manage all
interactions between a client and server in a unified way.
 All resources (or business data) involved in the client-server interactions are
dealt with a fixed set of operations.
The following are the core elements that form a uniform interface for a RESTful
system
 Resources and their identifiers
 The representation of resources
 Generic interaction semantics for the REST resources
 Self-descriptive messages
 Hypermedia as the engine of an application state
Fig 1. REST Architectural Elements

pg. 7
 Java | Rest

2. Connectors
Connectors provide decoupling between components by encapsulating the
underlying implementation of resources and communication mechanisms using
various connector types, as described in the following table:
Table 6. Connectors in context

Connector type Function Examples

Client Initiates the request and accepts the Client-side web APIs
response (libwww, libwww-perl)
Server Listens for connections and responds Web server APIs
to requests (Apache API, NSAPI)
Cache Used for storing cacheable responses Web caching solutions
both at the client and server side to (Akamai, Cloudflare,
optimize interaction latency Microsoft Azure CDN)
Resolver Resolves web address to the BIND, Microsoft DNS,
corresponding network address AnswerX
Tunnel Relays communication across a SOCKS, HTTP Tunnel
connection boundary such as
firewall, gateways, or proxies.

3. Components
Software components required for REST are categorized by their roles as
follows:
Table 7. Components in context

Component role Function Examples

Origin server It acts as the container or definitive Web servers
source for the representation of (Apache Tomcat, Microsoft
resources being requested; it must IIS)
be the ultimate recipient of any
requests. It uses a server connector
to receive and respond to requests.
User agent This is the user interface for the end Web browsers (Internet
user. It uses the client connector to Explorer, Chrome, Lynx)
pg. 8
 Java | Rest
initiate the request and get the
response.
Proxy This acts as an intermediary for CGI Proxy, CERN Proxy
requests from clients seeking
resources.
Gateway This involves reverse proxies Squid, NGINX
providing encapsulation of services
such as security (encryption),
performance enhancement (load
balancing), or data translation
(compression).

An overview of JAX-RS
There are multiple JAX-RS implementations available today by various vendors.
Some of the popular JAX-RS implementations are as follows
1. Jersey RESTful web service framework(https://jersey.github.io/)
2. Apache CXF (http://cxf.apache.org)
3. RESTEasy (http://resteasy.jboss.org)
4. Restlet (http://restlet.com)

pg. 9