Visvesvaraya Technological University

Belagavi, Karnataka-590 018

TECHNICAL SEMINAR REPORT

ON

“RESTful Web Services”

Submitted in partial fulfilment of the requirement for the award of the Degree
of

Bachelor of Engineering
In
Computer Science and Engineering
SUBMITTED BY:
Puneet Yadav
1JS18CS117

UNDER THE GUIDANCE OF

Mr. Sreenatha M
Assistant Professor, Dept of CSE,
JSSATE, Bengaluru

JSS Academy of Technical Education, Bengaluru

Department of Computer Science and Engineering
2021-2022
 JSS MAHAVIDYAPEETHA, MYSURU

JSS ACADEMY OF TECHNICAL EDUCATION

JSS Campus, Uttarahalli-Kengeri Main Road, Bengaluru – 560060

Department of Computer Science and Engineering

CERTIFICATE
This is to certify that Mr. Puneet Yadav bearing the USN 1JS18CS117, VIII
semester Bachelor of Engineering in Computer Science and Engineering has
presented and successfully completed the Technical Seminar titled “RESTful
Web Services” for the partial fulfilment for the award of Bachelor of
Engineering degree under Visvesvaraya Technological University Belagavi,
during the academic year 2021-2022.

Mr. Sreenatha M, Dr. Naveen N.C.,

Assistant Professor, Professor & Head of
Dept of CSE, Dept of CSE,
JSSATEB JSSATEB
 DECLARATION

I, Puneet Yadav, student of B.E. Computer Science and Engineering at JSS

Academy of Technical Education, Bengaluru, hereby declare that the
Technical Seminar entitled “RESTful Web Services” has been presented
independently at JSS Academy of Technical Education, Bengaluru.

Puneet Yadav
1JS18CS117
 ACKNOWLEDGEMENTS

The successful completion of any task would be incomplete without the mention of people
whose constant guidance and encouragement crowned my effort with success.

I express my gratitude to, Dr. Bhimasen Soragaon, Principal, JSS Academy of Technical
Education, for providing me excellent facilities and academic ambience which have helped
me in satisfactory completion of this Bachelor Degree.

I express my truthful thanks to Dr. Naveen N.C, Professor & HOD, Dept. of CSE, JSS
Academy of Technical Education, for his valuable support and encouragement.

I extend my sincere thanks and heartfelt gratitude to my panel members Mrs.

Bhavani.B.H, Asst. Professor, Dept. of CSE, and Mr. Sreenatha M, Asst. Professor,
Dept. of CSE JSS Academy of Technical Education, for their immense support, guidance
and ideas.

I would also like to thank the Seminar Coordinators for helping us present this seminar
successfully.

Finally, I take this opportunity to extend my earnest gratitude and respect to my parents,
teaching & non-teaching staffs of the department, the library staff and all my friends, who
have directly or indirectly supported me.

Regards,
PUNEET YADAV
[1JS18CS117]
JSSATE, Bengaluru-560060
 ABSTRACT

A Web service is a Web page that is meant to be consumed by an autonomous program.

Web service requires an architectural style to make sense of them as there need not be a
human being on the receiver end to make sense of them. REST (REpresentational State
Transfer) represents the model of how the modern Web should work. It is an architectural
pattern that distills the way the Web already works. REST provides a set of architectural
constraints that, when applied as a whole, emphasizes scalability of component
interactions, generality of interfaces, independent deployment of components, and
intermediary components to reduce interaction latency, enforce security, and encapsulate
legacy systems.

By its nature, user actions within a distributed hypermedia system require the transfer of
large amounts of data from where the data is stored to where it is used. Thus, the Web
architecture must be designed for large-grain data transfer. The architecture needs to
minimize the latency as much as possible. It must be scalable, secure and capable of
encapsulate legacy and new elements well, as Web is subjected to constant change. REST
provides a set of architectural constraints that, when applied as a whole, address all above
said issues.
 TABLE OF CONTENT

Chapter No. Chapter Name Page No.

1 Introduction 2-3

2 The Proposed System 4-10

2.1 REST Web Services characteristics 4
2.2 Principles of REST Web Services 5
2.3 RESTful Web Services Architecture 6-9
2.4 Advantages of Restful Web Services 10-11
2.5 Disadvantages of Restful Web Services 11-12
2.6 REST Design Guidelines 13

Conclusion 14

References 15-16
On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

CHAPTER 1

INTROUCTION
A Web service is a Web page that is meant to be consumed by an autonomous program.
Web Service requires an architectural style to make sense of them as there need not be a
human being on the receiver end to make sense of them. REST (Representational State
Transfer) represents the model of how the modern Web should Work. It is an
architectural pattern that distills the way the Web already works.
REST provides a set of architectural constraints that, when applied as a whole,
emphasizes Scalability of component interactions, generality of interfaces, independent
deployment of Components, and intermediary components to reduce interaction latency,
enforce security, and Encapsulate legacy systems.

A web service is nothing but a web page and it is consumed by an autonomous program.
The restful web services are a base of two vital factors and they are HTTP and REST. The
abbreviation of Representational State Transfer is known as REST and this explains about
architectural principles. With the avail of these principles, one can create a web service
that focuses on the resource of the system and this also includes the addresses of resource
states and transferring of resource states over HTTP by a large number of clients written
in various languages. From the last two years, the REST is the one and only predominant
model of web service, it is so simple to use that it has replaced many interface designs
based on SOAP and WSDL.

What is REST?

REST defines a set of architectural principles by which you can design Web services that
focus on a system's resources, including how resource states are addressed and transferred
over HTTP by a wide range of clients written in different languages. If measured by the
number of Web services that use it, REST has emerged in the last few years alone as a
predominant Web service design model. In fact, REST has had such a large impact on the
Web that it has mostly displaced SOAP- and WSDL-based interface design because it's a
considerably simpler style to use.

RESTful web services are built to work best on the Web. Representational State Transfer
(REST) is an architectural style that specifies constraints, such as the uniform interface,
that if applied to a web service induce desirable properties, such as performance,
scalability, and modifiability, that enable services to work best on the Web. In the REST
architectural style, data and functionality are considered resources and are accessed
using Uniform Resource Identifiers (URIs), typically links on the Web. The resources
are acted upon by using a set of simple, well-defined operations. The REST architectural
style constrains an architecture to a client/server architecture and is designed to use a
stateless communication protocol, typically HTTP. In the REST architecture style, clients
and servers exchange representations of resources by using a standardized interface and
protocol.

Dept Of CSE, JSSATEB 2

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

The following principles encourage RESTful applications to be simple, lightweight, and

fast:
• Resource identification through URI: A RESTful web service exposes a set of
resources that identify the targets of the interaction with its clients. Resources are
identified by URIs, which provide a global addressing space for resource and
service discovery.
• Uniform interface: Resources are manipulated using a fixed set of four create,
read, update, delete operations: PUT, GET, POST, and DELETE. PUT creates a
new resource, which can be then deleted by using DELETE. GET retrieves the
current state of a resource in some representation. POST transfers a new state onto
a resource.
• Self-descriptive messages: Resources are decoupled from their representation so
that their content can be accessed in a variety of formats, such as HTML, XML,
plain text, PDF, JPEG, JSON, and others. Metadata about the resource is available
and used, for example, to control caching, detect transmission errors, negotiate the
appropriate representation format, and perform authentication or access control.
• Stateful interactions through hyperlinks: Every interaction with a resource is
stateless; that is, request messages are self-contained. Stateful interactions are
based on the concept of explicit state transfer. Several techniques exist to
exchange state, such as URI rewriting, cookies, and hidden form fields. State can
be embedded in response messages to point to valid future states of the
interaction.

Dept Of CSE, JSSATEB 3

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

CHAPTER 2

THE PROPOSED SYSTEM

2.1 REST Web Services Characteristics

Here are the characteristics of REST:

Client-Server: a pull-based interaction style: consuming components pull

representations.

Stateless: each request from client to server must contain all the information necessary
to understand the request, and cannot take advantage of any stored context on the server.

Cache: to improve network efficiency responses must be capable of being labeled as

cacheable or non-cacheable.

Uniform interface: all resources are accessed with a generic interface (e.g., HTTP
GET, POST, PUT, DELETE).

Named resources - the system is comprised of resources which are named using a
URL.

Interconnected resource representations - the representations of the resources are

interconnected using URLs, thereby enabling a client to progress from one state to
another.

Layered components - intermediaries, such as proxy servers, cache servers, gateways,

etc, can be inserted between clients and resources to support performance, security, etc.

Dept Of CSE, JSSATEB 4

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

2.2 Principles of REST Web Service Design

1. The key to creating Web Services in a REST network (i.e., the Web) is to identify all of
the conceptual entities that you wish to expose as services. Above we saw some examples
of resources: parts list, detailed part data, purchase order.

2. Create a URL to each resource. The resources should be nouns, not verbs. For example,
do not use this:
http://www.parts-depot.com/parts/getPart?id=00345

Note the verb, getPart. Instead, use a noun:

http://www.parts-depot.com/parts/00345

3. Categorize your resources according to whether clients can just receive a representation
of the resource, or whether clients can modify (add to) the resource. For the former, make
those resources accessible using an HTTP GET. For the later, make those resources
accessible using HTTP POST, PUT, and/or DELETE.

4. All resources accessible via HTTP GET should be side-effect free. That is, the resource
should just return a representation of the resource. Invoking the resource should not result
in modifying the resource.

5. No man/woman is an island. Likewise, no representation should be an island. In other

words, put hyperlinks within resource representations to enable clients to drill down for
more information, and/or to obtain related information.

6. Design to reveal data gradually. Don't reveal everything in a single response document.
Provide hyperlinks to obtain more details.

7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or
Schematron). For those services that require a POST or PUT to it, also provide a schema
to specify the format of the response.

8. Describe how your services are to be invoked using either a WSDL document, or
simply an HTML document.

Dept Of CSE, JSSATEB 5

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

2.3 RESTful Web Services Architecture

REST stands for REpresentational State Transfer and API stands for Application Program
Interface. REST is a software architectural style that defines the set of rules to be used
for creating web services. Web services which follow the REST architectural style are
known as RESTful web services. It allows requesting systems to access and manipulate
web resources by using a uniform and predefined set of rules. Interaction in REST based
systems happen through Internet’s Hypertext Transfer Protocol (HTTP).

A Restful system consists of a:

• client who requests for the resources.
• server who has the resources.

It is important to create REST API according to industry standards which results in ease
of development and increase client adoption.
Architectural Constraints of RESTful API: There are six architectural constraints
which makes any web service are listed below:
• Uniform Interface
• Stateless
• Cacheable
• Client-Server
• Layered System
• Code on Demand

The only optional constraint of REST architecture is code on demand. If a service

violates any other constraint, it cannot strictly be referred to as RESTful.
Uniform Interface: It is a key constraint that differentiate between a REST API and
Non-REST API. It suggests that there should be an uniform way of interacting with a
given server irrespective of device or type of application (website, mobile app).
There are four guidelines principle of Uniform Interface are:

• Resource-Based: Individual resources are identified in requests. For

example: API/users.

• Manipulation of Resources Through Representations: Client has

representation of resource and it contains enough information to modify or
delete the resource on the server, provided it has permission to do so.
Example: Usually user get a user id when user request for a list of users and
then use that id to delete or modify that particular user.

Dept Of CSE, JSSATEB 6

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

• Self-descriptive Messages: Each message includes enough information to

describe how to process the message so that server can easily analyses the
request.

• Hypermedia as the Engine of Application State (HATEOAS): It need to

include links for each response so that client can discover other resources
easily.

Stateless: It means that the necessary state to handle the request is contained within the
request itself and server would not store anything related to the session. In REST, the
client must include all information for the server to fulfill the request whether as a part
of query params, headers or URI. Statelessness enables greater availability since the
server does not have to maintain, update or communicate that session state. There is a
drawback when the client need to send too much data to the server so it reduces the
scope of network optimization and requires more bandwidth.

Cacheable: Every response should include whether the response is cacheable or not and
for how much duration responses can be cached at the client side. Client will return the
data from its cache for any subsequent request and there would be no need to send the
request again to the server. A well-managed caching partially or completely eliminates
some client–server interactions, further improving availability and performance. But
sometime there are chances that user may receive stale data.

Client-Server: REST application should have a client-server architecture. A Client is

someone who is requesting resources and are not concerned with data storage, which
remains internal to each server, and server is someone who holds the resources and are
not concerned with the user interface or user state. They can evolve independently.
Client doesn’t need to know anything about business logic and server doesn’t need to
know anything about frontend UI.

Layered system: An application architecture needs to be composed of multiple layers.

Each layer doesn’t know any thing about any layer other than that of immediate layer
and there can be lot of intermediate servers between client and the end server.
Intermediary servers may improve system availability by enabling load-balancing and
by providing shared caches.

Code on demand: It is an optional feature. According to this, servers can also provide
executable code to the client. The examples of code on demand may include the
compiled components such as Java applets and client-side scripts such as JavaScript.

Dept Of CSE, JSSATEB 7

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

Fig. RESTful Web Services Architecture

Rules of REST API: There are certain rules which should be kept in mind while
creating REST API endpoints.

• REST is based on the resource or noun instead of action or verb based. It

means that a URI of a REST API should always end with a noun. Example:
/api/users is a good example, but /api?type=users is a bad example of
creating a REST API.

• HTTP verbs are used to identify the action. Some of the HTTP verbs are –
GET, PUT, POST, DELETE, UPDATE, PATCH.

• A web application should be organized into resources like users and then
uses HTTP verbs like – GET, PUT, POST, DELETE to modify those
resources. And as a developer it should be clear that what needs to be done
just by looking at the endpoint and HTTP method used.

HTTP verbs: Some of the common HTTP methods/verbs are described below:

• GET: Retrieves one or more resources identified by the request URI and it
can cache the information receive.

• POST: Create a resource from the submission of a request and response is

not cacheable in this case. This method is unsafe if no security is applied to
the endpoint as it would allow anyone to create a random resource by
submission.

Dept Of CSE, JSSATEB 8

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

• PUT: Update an existing resource on the server specified by the request

URI.

• DELETE: Delete an existing resource on the server specified by the request

URI. It always return an appropriate HTTP status for every request.

• GET, PUT, DELETE methods are also known as Idempotent methods.

Applying an operation once or applying it multiple times has the same effect.
Example: Delete any resource from the server and it succeeds with 200 OK
and then try again to delete that resource than it will display an error
message 410 GONE.

Dept Of CSE, JSSATEB 9

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

2.4 Advantages
1. Easy to integrate

A decent RESTful API may be found from the very first URI. This isn’t to say that each
application that uses your service will know what to do automatically. It does, however,
make things easier for the developer who is attempting to connect your API.

2. Use of HTTP

The usage of ubiquitous standards is another characteristic for ease of integration that has
to do with REST over HTTP (THE most popular implementation of REST). Speaking of
HTTP, the web’s protocol, and outputting JSON or ATOMPub means finding a library
that can connect to you in any language and the platform is much easier.

3. Scalability

Stateless communication and a replicated repository provide a high level of scalability.

With the REST APIs, scaling up an existing website is easier when it is compared with
something like SOAP.

4. Independence

Because of the separation between client and server, the REST protocol allows for
autonomous development across several sections of a project. Furthermore, the REST
API is adaptable to operational syntax and platform. This allows testing in a variety of
contexts throughout development.

5. Uniform Interface

When creating a REST API, developers agree to follow the same standards. Hence, the
output is a consistent interface across all APIs. This interface functions as a contract
between the client and the service, and it is shared by all REST APIs. How is this
useful? When developers utilize APIs, they require global ideas to ensure that they can
communicate with one another.

6. Layered System

Every REST-enabled component has no access to components other than the one with
whom it is communicating. This means, that a client who connects to an intermediary
component does not know with whom that component will engage later. This encourages
developers to design separate components that are easy to upgrade.

Dept Of CSE, JSSATEB 10

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

2.4.1 REST advantages over SOAP

REST overcomes many of the disadvantages of SOAP, such as the need for clients to know
the operation semantics as a pre-requisite for its use, or the use of different ports for
different types of notifications. In addition, REST can handle many resources,
while SOAP needs many operations to accomplish that.

These are some of the advantages of REST:

• It is usually simple to build and adapt.

• Low use of resources.
• Process instances are created explicitly.
• With the initial URI, the client does not require routing information.
• Clients can have a generic ‘listener’ interface for notifications.
• Scalable Component Interactions.
• Independently deployed connectors.
• Reduced interaction latency.
• Strengthened security.
• Safe encapsulation of legacy systems.
• Supports intermediaries (proxies and gateways) as data transformation and
caching components.
• Separates server implementation from the client’s perception of resources (“Cool
URIs Don’t Change”).
• Scales well to large numbers of clients.
• Enables transfer of data in streams of unlimited size and type.

2.5 Disadvantages
• Lack of state: most web applications require stateful mechanisms. Suppose you
purchase a website which has a mechanism to have a shopping cart. It is required
to know the number of items in the shopping cart before the actual purchase is made.
This burden of maintaining the state lies on the client, which makes the client
application heavy and difficult to maintain.

• Last of security: REST doesn’t impose security such as SOAP. That is the reason
REST is appropriate for public URLs, but it is not good for confidential data passage
between client and server.

• Communication: Since there is no contract defined between service and client, it

has to be communicated through other means such as documentation or emails.

• Async Calls: Since it works on HTTP, there can’t be asynchronous calls.

Dept Of CSE, JSSATEB 11

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

• Sessions: Sessions can’t be maintained.

• It sacrifices some of the advantages of other architectures.

• Stateful interaction with an FTP site.

• It retains a single interface for everything.

The stateless constraint reflects a design trade-off. The disadvantage is that it may decrease
network performance by increasing the repetitive data (per-interaction overhead) sent in a
series of requests, since that data cannot be left on the server in a shared context. In addition,
placing the application state on the client-side reduces the server’s control over consistent
application behaviour, since the application becomes dependent on the correct
implementation of semantics across multiple client versions.

Dept Of CSE, JSSATEB 12

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

2.6 REST Design Guidelines

Some soft guidelines for designing a REST architecture:

1. Do not use "physical" URLs. A physical URL points at something physical -- e.g., an
XML file: "http://www.acme.com/inventory/product003.xml". A logical URL does not
imply a physical file: "http://www.acme.com/inventory/product/003".

• Sure, even with the .xml extension, the content could be dynamically generated.
But it should be "humanly visible" that the URL is logical and not physical.

2. Queries should not return an overload of data. If needed, provide a paging mechanism.
For example, a "product list" GET request should return the first n products (e.g., the first
10), with next/prev links.

3. Even though the REST response can be anything, make sure it's well documented, and
do not change the output format lightly (since it will break existing clients).

• Remember, even if the output is human-readable, your clients aren't human users.
• If the output is in XML, make sure you document it with a schema or a DTD.

4. Rather than letting clients construct URLs for additional actions, include the actual
URLs with REST responses. For example, a "product list" request could return an ID per
product, and the specification says that you should use
http://www.acme.com/product/PRODUCT_ID to get additional details. That's bad design.
Rather, the response should include the actual URL with each item:
http://www.acme.com/product/001263, etc.

• Yes, this means that the output is larger. But it also means that you can easily
direct clients to new URLs as needed, without requiring a change in client code.

5. GET access requests should never cause a state change. Anything that changes the
server state should be a POST request (or other HTTP verbs, such as DELETE).

Dept Of CSE, JSSATEB 13

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

CONCLUSION
Service-Oriented Architecture can be implemented in different ways. General focus is on
whatever architecture gets the job done. SOAP and REST have their strengths and
weaknesses and will be highly suitable to some applications and positively terrible for
others. The decision of which to use depends entirely on the circumstances of the
application.

So, to conclude, REST is a type of data transfer that is built upon the architecture of the
HTTP protocol. It allows you to easily send and retrieve data between two different services
using XML or JSON.

When structuring your web applications, it’s usually good practice to build them using
RESTful architecture. This means that collections and resources are easily recognised and
can form the basis of building a RESTful API.

When you build an application that requires a JavaScript heavy front-end, or integration
with a smartphone application, using a RESTful architecture becomes a necessity because
it allows you to transfer data from the API to the client. It’s often good practice to plan
out your RESTful collections and resources at the very outset.

So, the next time you start a web application project, think about how you can make it
more RESTful. It will probably not only make your application’s architecture better, but
it will also allow you to easily build an API in the future to integrate with other services
or applications.

Dept Of CSE, JSSATEB 14

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

REFERENCES
[1] D. Denoncourt, "How to Put Ajax JSON REST and RPG to Work Creating an RPG
Browser", System iNEWS, no. 369, pp. 9-15, July 2010.

https://scholar.google.com/scholar?as_q=How+to+Put+Ajax%2C+JSON%2C+REST%2
C+and+RPG+to+Work+Creating+an+RPG+Browser&as_occt=title&hl=en&as_sdt=0%2
C31

[2] Y.-H. Chen, P.-C. Su, and F.-T. Chien, ‘‘Air-writing for smart glasses by effective
fingertip detection,’’ in Proc. IEEE 8th Global Conf. Consum. Electron. (GCCE), Oct.
2019, pp. 381–382, doi: http://dx.doi.org/10.1109/GCCE46687.2019.9015389

[3] R. Ferro, W. R. Martinez and Y. Diaz, "EasyChair Preprint Development of a WEB

prototype based on JSON and REST technology to manage progress in the physical and
psych", scholar.googleusercontent.com, 2018, [online] Available:
https://scholar.googleusercontent.com/scholar?q=cache:vnWXRJzyjigJ:scholar.google.co
m/+Mart%C3%ADnez.

[4] C. M. Garcia and R. Abilio, Systems Integration Using Web Services REST and SOAP:
A Practical Report, 2017.

https://scholar.google.com/scholar?as_q=Systems+Integration+Using+Web+Services%2
C+REST+and+SOAP%3A+A+Practical+Report&as_occt=title&hl=en&as_sdt=0%2C31

[5] E. John and M. Siddique, "Efficient Semantic Web Services Development Approaches
using REST and JSON," 2021 International Conference on Decision Aid Sciences and
Application (DASA), 2021, pp. 231-235,

doi: https://doi.org/10.1109/DASA53625.2021.9682324

[6] A. Solichin, M. Andika Putra and K. Diniari, "RESTful Web Service Optimization with
Compression and Encryption Algorithm," 2018 International Seminar on Application for

Dept Of CSE, JSSATEB 15

On-Air Hand-Drawn Doodles for IoT Devices Authentication During COVID-19

Technology of Information and Communication, 2018, pp. 333-337, doi:

https://doi.org/10.1109/ISEMANTIC.2018.8549727

[7] I. Ahmad, E. Suwarni, R. I. Borman, Asmawati, F. Rossi and Y. Jusman,

"Implementation of RESTful API Web Services Architecture in Takeaway Application
Development," 2021 1st International Conference on Electronic and Electrical Engineering
and Intelligent System (ICE3IS), 2021, pp. 132-137, doi:
https://doi.org/10.1109/ICE3IS54102.2021.9649679

Dept Of CSE, JSSATEB 16