Description

The goal of this course is to

teach you how to use the
REST API with Spring.

Author: Mihai Andrei PASCAL

REST WITH SPRING

Java Spring Framework (REST API)
Java Core 8 Pascal Mihai Andrei

Table of Content
1. The Basic of Rest with Spring ........................................................................................ 2
1.1. Constraints ............................................................................................................. 4
1.2. Terminologies .......................................................................................................... 4

1|P a g e
Java Core 8 Pascal Mihai Andrei

1. The Basic of Rest with Spring

REST (Representational State Transfer) is an architectural style for designing network applications,
driven by a set of constraints and inspired from the architecture of the Web.
In theory, REST is entirely separate from the HTTP protocol, but in practice we're primarily building
APIs on top of HTTP. So the goal is to leverage the full semantics of the protocol and use it as an application
protocol (rather than just transport).

Fig.1.1 – Rest Architecture

In REST based architecture everything is a resource. A resource is a data on which we want to
perform operations, which means that this data can be present on the database on the server side. So in a rest-
based architecture you have a rest server which provides the access to the resource (which can be in a database
or in some form of records).
For example, we want to create a weather app. Now, weather app is dependent on the weather data.
Let's say this weather data is saved every day or every hour in some database, which can be accessed from a
rest server. So, in a rest-based architecture you have a REST-server which provides an access to the resource
(in our case it's a weather data of some city) and you also have a REST-client which can access or modify
the rest resource. Every resource should support the HTTP common operation. This resource is identified
using a global ID which are typically called URI (Uniform Resource identifier) and in some cases it's called
URL (Uniform Resource Locator), so you can consider this URI as an address of the resource (in order to
identify it). So, for example we want to access the temperature of City London. This request can be sent from
a client in the form of URI under the country name UK and then the resource named London.
Rest allows the resource to have different representations. For example, we send a request to a rest
server and on the request this rest server accesses the London's temperature report and then how or in which
representation it should send the result and in which format this data is returned to the client is called a
Representation.
Rest allows this resource to have different representation. It can send an XML representation of the result
or it can send JSON representation of the result or in most of the cases it can also send HTML as a
representation. In rest, clients decide which kind of representation it want to have. So for example, the client
sends this information, that he wants the result in the representation of a JSON. Client send this request to
the server, and tells him what kind of representation it wants.

2|P a g e
Java Core 8 Pascal Mihai Andrei

Fig.1.2 – Meaning of Representational State Transfer.

Is called Representation State Transfer, because the request can be sent in the form of a JSON or text or
HTML or XML. So we are using the representation of a resource to transfer this resource state, which lives
on the server-side, into the application state which belongs to the client-side. The client is the one who possess
the necessary information to identify, modify or delete a web resource and it also decides which form of
representation should receive, because all resource state information is stored on the client-side, so this means
that the server-side is stateless.
HTTP methods supported by REST:
 GET  retrieve the representation of resource
 PUT  update/modify existing resource (or create a new resource if doesn’t exist)
 POST  create a new resource
 DELETE  delete an existing resource
 HEAD  fetch meta-data of representation only
 OPTIONS  check which HTTP methods a particular resource supports

Architecture Principles:
 Everything is a resource in REST architecture style, data and functionality are considered resources
and are accessed using Uniform Resource Identified (URI), typically links inn the Web.
 Every resource is identified by a Unique Identifier (URI).
 Use simple and uniform interfaces.
 Communication is done by representation. So Rest will send a representation in the form of XML or
JSON or text or any other form on the clients request
 Be stateless.

Fig.1.3 Architecture of a rest application (Twitter).

REST API is an application program interface that uses HTTP request to get, put, post and delete
some resources.
For example, let’s say we have a resource called dishes inside a kitchen. So now a client comes and he
wants to order some dishes from the kitchen but he cannot directly go to the kitchen and then take whatever

3|P a g e
Java Core 8 Pascal Mihai Andrei

he wants, so the user uses some intermediate service to access this resource and this is the job of an API
which is waiter in our case, so a REST API accesses this resource on the clients request and then responds
this representation of the result to the client.
For example, if a client wanted to invoke a web service that lists all of the quizzes available here at
TechTarget, the URL to the web service would look something like this:
www.techtarget.com/restfulapi/quizzes. When invoked, the web service might respond with the
following JSON string listing all of the available quizzes, one of which is about DevOps:
{ "quizzes" : [ "Java", "DevOps", "IoT"] }.
To get the DevOps quiz, the web service might be called using the following URL:
www.techtarget.com/restfulapi/quizzes/DevOps.
Invoking this URL would return a JSON string listing all of the questions in the DevOps quiz. To get
an individual question from the quiz, the number of the question would be added to the URL. So, to get the
third question in the DevOps quiz, the following RESTful URL would be used:
www.techtarget.com/restfulapi/quizzes/DevOps/3.
Invoking that URL might return a JSON string such as the following:
{ "Question" : {"query":"What is your DevOps role?", "optionA":"Dev", "optionB":"Ops"} }.

1.1. Constraints
1) Client-Server  This fundamental constraint enforces a separation of concerns and enables
independent evolution of the Client and the Server.
2) Stateless  The communication between Client and Server must be stateless between requests.
First – the obvious part: each request from a client should contain all the necessary information for
the service to complete the request. Then, the more non-obvious part: all session state data should
then be returned to the client at the end of each request.
3) Cache  All responses from the Server should be explicitly labeled as cacheable or non-cacheable.
Requests should pass through a Cache Component – which can partially or fully eliminate some
interactions with the Server. The results are improved efficiency and scalability by matching and
utilizing the already available huge infrastructure of the Web.
4) Interface / Uniform Contract  The Service and all Clients must share a single uniform technical
interface. In order for that interface to be reusable by a wide range of Clients, it needs to provide
generic, high-level capabilities that are abstract enough to accommodate a broad range of
interactions.
5) Layered System  This constraint builds on Client-Server Constraint to allow for Intermediaries /
Middleware. There intermediaries must be fully transparent for the Client. The interaction between
a Service and a Client should be consistent, regardless if the Client is communicating directly with
the ultimate receiver of a message or not. Similarly, the Service does not need to be aware of
whether the Client is itself acting as a service for other Clients or if it’s the actual origin. This kind of
information hiding greatly simplifies the distributed architecture of the system and allows individual
architectural layers to be deployed and evolved independently of specific service and consumers.

1.2. Terminologies
1) Resource  The Resource is the key abstraction of information in REST. Any information that can
be named / identified via a unique, global id (the URI) – is a Resource.
2) Representation  Any given Resource can have multiple Representations; these capture the
current state of the Resource in a specific format. At the lowest level, the Representation is “a
sequence of bytes, plus representation metadata to describe these bytes”.
3) Hypermedia Types  There are several Hypermedia types we can use for our Representations, and
we can build our own if we need to. IMPORTANT: JSON is not a Hypermedia.

4|P a g e