University of Bedfordshire

Distributed and parallel computing technologies

Topic: REST and JSON

Student Name and ID

Suraj Timilsina 1959410
Kaladevi Suresh 1956841
Neha Nakrani 1956026
Vamshi Krishna Kongara 1844255
Vignesh Thiruvengada Moorthy 1943190

REST and JSON

Suraj Timilsina (1959410) Vamshi Krishna Kongara (1844255)
Department of CST Department of CST

University of Bedfordshire University of Bedfordshire

Luton, United Kingdom Luton, United Kingdom
Email: suraj.timilsina@study.beds.ac.uk Email: Vamshi.Kongara@study.beds.ac.uk

Kaladevi Suresh (1956841) Vignesh Thiruvengada Moorthy (1943190)

Department of CST Department of CST

University of Bedfordshire University of Bedfordshire

Luton, United Kingdom Luton, United Kingdom
Email: Kaladevi.suresh @study.beds.ac.uk Email: vignesh.thiruvengadamoorthy@study.beds.ac.uk

Neha Nakrani (1956026)

Department of CST
University of Bedfordshire
Luton, United Kingdom

Email: NehaVasantbhai.Nakrani@study.beds.ac.uk

ABSTRACT:
This paper discuss the REST API and JSON data format that is used to transfer data between the two parties.
Each and every journal used to review are based on how rest web services works or designed on various
systems. The main aspects of rest api along with its principles and constraints are detailed in the paper. This also
includes the detailed explanation of how the rest pi can be used to design cross terminal web system and
construction of knowledge graphs, and a sample student information system is designed to implement basic rest
call to add or modify or delete and get student details in a secure way using JWT and how to create a JWT token
the syntax of the token and how it is used to access the subsequent client request has been given. Once the
application is designed and implemented the rules on how to test the application is explained. The main aim of
this paper is to summaries the already existing journals of REST and JSON and its implementation and the
secured way of transferring the data between client and server using JWT on a sample student information
system a spring boot application is discussed. The drawbacks of REST api and the introduction of GraphQL
which overcomes the draw backs of REST API are also explained in this paper.
Table of Contents
1. Introduction 5

2. Review by Vamshi Krishna 5

Existing framework 5
Architecture Overview 6
Main process and modules 6
Use case 7
3. Review by Vignesh Tiruvengada Moorthy…………………………………………………………………………7

Comparing XML and JSON 7

Comparing RCPFul and RestFul 8

Web services design on service 8

Design on client system 9

4. Review by Neha Nakrani…………………………………………………………………………………………………….9

About Test API testing Model 10

Rest API test methodology 10
Test case of REST and JSON 11
Beyond the REST and JSON 11
5. Review by Suraj Timilsina …………………………………………………………………………………………11

REST APIs 11
Rest API Best Practices 12
Mobile Internet Traffic analysis 12
REST API analysis using data sets …………………………………………………………………………………..12
6. Review by Kaladevi Suresh ………………………………………………………………………………………….12

REST and JSON 12

What is JWT? ………………………………………………………………………………………………………………….13
Structure of JWT ……………………………………………………………………………………………………………13
How JWT works? 14
Student Information System(implementation of JWT )? 14
7. Discussions …………………………………………………………………………………………………………. 15
8. Conclusion …………………………………………………………………………………………………………. 16
9. Referneces ………………………………………………………………………………………………………… 16
10. Appendix …………………………………………………………………………………………………………. 17

1. Introduction
The REST stands for Representational State transfer an architecture for distributed systems which was first
presented by Roy Fielding in the year 2000. Rest has its own guiding principles and constraints so an
application or architecture considered RESTful or REST-style if the state and functionality are divided into
distributed resources which means that every resource should be accessible via the normal http commands of
get, post, put, or delete. So if someone wanted to get a file from a server, they should be able to issue the get
request and get the file. If they want to put a file on the server, they should be able to either issue the post or put
request. And finally, if they wanted to delete a file from the server, they an issue the delete request. The
architecture is client/server, stateless, layered, and supports caching Client-server is the typical architecture
where the server can be the web server hosting the application, and the client can be as simple as the web
browser then stateless means that the state of the application is not maintained in rest. For example, if you delete
a resource from a server using the delete command, you cannot expect that delete information to be passed to
the next request. In order to ensure that the resource is deleted, you would need to issue the get request. The get
request would be used to first get all the resources on the server. After which one would need to see if the
resource was actually deleted. This is the most fundamental requirement of a REST based architecture. It means
that the server will have a RESTful web service which would provide the required functionality to the client.
The client send’s a request to the web service on the server. The server would either reject the request or comply
and provide an adequate response to the client. JSON (JavaScript Object Notation) is the most widely used data
format for data interchange on the web. This data interchange can happen between two computer applications at
different geographical locations or running within the same machine JSON is a human-readable as well as a
machine-readable format. So while applications/libraries can parse the JSON documents humans can also look
at the data and derive the meaning from it. All modern programming languages like Java, JavaScript, Ruby, C#,
PHP, Python, and Groovy and application platforms provide excellent support for producing and consuming
JSON data. This paper reviews various journals about rest API services and implementation of those services in
detail.

2. Review by VAMSHI KRISHNA
KONGARA- 1844255
Knowledge graphs construction using RESTful
API and JSON Schema
The large volumes of data that has been generated
from different kinds of applications and user
interactions requires immediate data processing to
identify and generate useful information by
applying different data mining techniques. Another
important aspect of data mining is data
visualisation process which allows the data
scientists to represent the data that has been
processed into a visualised procedure that helps in
analysing the results in a much efficient way. There
are different kinds of data visualisation techniques
that are being used currently among which
collaboration sporting is one of the key platforms
which is used for representing data that has been
collected and processed from heterogeneous
sources. While processing large amounts of data
and identifying useful knowledge which is known
as knowledge representation, knowledge graphs are
key graphical structured elements which will be
used in the data models to represent data in the
form of events and abstract concepts which helps in
identifying the interlinked associations between
different data elements and components. The
knowledge graphs are very popular in the semantic
web which will help in identifying the concepts and
connections between different entities which will
are being used by the popular search engines such
as Google and Yahoo in establishing different key
network links which are efficiently useful for some
of the popular social network sites such as
Facebook and LinkedIn. In this research review, we
are going to discuss about an effective
representation of knowledge graphs by integration
of the RESTful API style along with JSON meta
schema which helps in creation of an application
programming interface which helps data processing
users in defining data elements without any
restriction and generating efficient visualisation
analytics for end users [1].
Existing framework:
The collaboration spotting CS is the popular
platform used for visualisation analytics generation
such as knowledge graphs which uses data mining
procedures to collect data from heterogeneous data
sources and organise them in a structural format to
generate different perspective using various
graphical algorithms and data mining techniques
however, with enhanced data structures and
improved data mining procedures the collaboration
spotting requires further adjustments and
modifications in order to analyse publications and
support new data visualization innovations. The
primary focus on the API structure that is being
represented in this paper is to provide support for
the creation of descriptors which will help the data
scientists to describe data elements without any
restrictions and to support the implementation of
ontology and data hierarchy related procedures
with controlled parameters which will help in
implementation of data driven platforms. The
newly designed architecture should also be able to
upload data and upload descriptors using
predefined nodes and edge description mechanisms
that should help the users to represent output data
in multiple visualisation procedures. The further
details about the proposed architecture and its use
cases will be reviewed in the upcoming sections of
this review paper.
Architecture overview
The architecture of the proposed application
programming interface for knowledge graphs
construction should match with certain
requirements such as the implementation of
graphical database which helps the representation
of visual analytics and knowledge graphs using
different vertices and edges that are being utilised
in the visual representation. Apart from that, the
web framework that is being developed should also
have the ability of implementing Django based
framework in python along with implementation of
JSON framework for data exchange between
different platform-based application layers.
Figure 1- Proposed architectural model overview
[2]
The above figure gives an overview of architectural
model that has been specified for collaboration
spotting application programming interface where
we can see multiple data processing steps that are
being highlighted. The simplified data model
consists of RESTful API interface which has
connections extended with RESTful message
services from the clients and generating and re-
routing the responses back. Additionally, the Neo4j
interface has been used to establish connection
between the RESTful calls where the project
manager extends its connection to data validator
component which users predefined descriptors and
data analytic tools that are being highlighted. The
outcomes of the project will be managed by the
project manager module which is located within the
architectural model in forwarding messages from
the interfaces. The main categories of the
architectural model include creating a project,
uploading the descriptors and then further
processing, and uploading the data which will be
represented as series of processes and modules
associated with in the architectural model diagram
[2].
Main processes and modules
The key processes that are being associated with in
the proposed architectural model will be managed
by the project manager module which accepts the
HTTP messages and then redirecting them into
JSON meta schema validator. The detailed steps
and procedures that are being followed within
upload data process has been highlighted in the
following figure where we can see different HTTP
methods such as put and get where the data will be
traversed using multiple single node mechanisms
following which the project will be selected and
data validation will be performed after which the
JSON meta schema will perform find descriptor
procedure where the data will be validated before
storing the data inside the project manager module
where the Neo4J interface will come into picture
before generating corresponding errors and creation
of restful API interface. The following figure gives
detailed overview of the series of steps that are
being followed by different modules within the
upload data procedures implemented inside the
architectural module.
Figure 2- upload descriptor and data steps overview
[2]
The JSON documents will be uploaded into the
descriptor module of architectural diagram using
upload data process and upload descriptor process
which will further initiate the data execution
process before generating corresponding response
messages that are being traversed into the interface
module for visualisation in the form of knowledge
graphs [2].
Use-case
The uploading time and processing times of the
proposed architectural model has been reviewed to
determine their efficiency within the Neo4j
database to determine its use case. The individual
descriptors have generated higher efficiency while
validating JSON documents within the databases
which clearly represent the efficiency of design and
architecture that has been proposed. The simplified
database model which has been used is represented
in the following figure where we can see different
events and attributes that are being used within the
data validation procedure including different
methods that are used. The key elements that are
used within the descriptors such as graph elements
which is used for representing individual
descriptors that are used for defining the descriptor
roles along with descriptors and mandatory labels
which are used on both source and target nodes has
been evaluated using the following events to
determine that working efficiency of proposed
model.
Figure 2- Data base model used for model ranking
[2]
The proposed architectural model with the
combination of restful API services along with
JSON based metadata schema for creation of
knowledge graphs has given us insight into
different data processing elements such as
descriptors and data construction elements which
are key components of collaboration spotting
platform which has been evaluated in this research
paper. The extension of JSON meta schema had
helped in efficient processing of data descriptors
and representing the data in a wide visual analytics
format with a smaller number of controls and risk
mechanisms which is considered as an efficient
way of representing heterogeneous data. The
research also suggests improvements for the future
where the standard version of JSON schema can be
replaced with alternate solutions such as LD JSON
which has additional powers in terms of
verification and ontology structural representation
that supports knowledge graphs construction.
3. Review by Vignesh Thiruvengada
Moorthy - 1943190
Designing a Cross-terminal Web System Based
on JSON and REST
The existing web services-based systems and
applications design have difficulties in providing a
platform which is accessible from different kinds of
applications and systems configuration. One of the
primary issues associated with such design is data
exchange where the efficiency of data exchange is
quite low and the associated complex interfaces
where the data exchange between the applications
become more complex. Apart from that, the
corresponding restrictions in terms of expanding
the application framework or modifying any
existing design is quite complex in terms of cross
terminal systems where different kinds of
application-based browsers and operating systems
involved. For this purpose, in this research we are
reviewing a cross terminal-based systems design
which will be developed using JSON data format
and RESTful web services that supports highly
efficient data exchange and allows for expansion of
interfaces and its associated design without any
complex technical issues. For this purpose, we will
be reviewing and comparing the XML and JSON
data formats initially and provide a detailed
comparison between the traditional RPCful and
RESTful based web services in order to determine
how efficient the RESTful API services will be on
the cross-terminal web system-based design [1].
The further sections of this review will discuss in
detail about the comparison and associated results
along with a detailed solution design in terms of
server-side components and corresponding design
along with a detailed design on client side which
will be evaluated in terms of system performance
and data exchange rates.
Comparing XML and JSON
The comparison between XML and JSON will be
performed by evaluating two different parameters
such as data volume and parsing process which are
helpful in understanding the significant differences
between both of them. XML is traditional data
organising process in which there will be different
key value combinations along with certain tags for
storing the information against individual
parameters. There will be multiple number of tags
for each field which will further extends its value
of the key whereas JSON data format is completely
different where we have data that is being
represented in the form of arrays which helps
primarily in a case when there are duplicate data.
This clearly indicates that the data volume
associated in JSON is significantly smaller
compared to the data volumes on XML which helps
in efficiently processing the data and compressing
it under different network and bandwidth related
conditions. These attributes are compared against
the inefficiency of data exchange between the
server and client systems while developing a cross
terminal-based application system. Additionally, it
is technically proven that JSON data parsing is
highly efficient and faster compared with XML
data parsing because of the document object model
that is being deployed whereas in case of JSON, the
notation of JavaScript can be easily possible and
simple for the client system to display the
interfaces within short execution [2].
Comparing RPCful and RESTful services
The earlier section provided detailed comparison
between the XML and JSON data formats in terms
of data volumes processing and also parsing
procedures and, in this section, we are going to
quickly compare the architectural procedures that
are being followed in RPC based architecture and
RESTful services-based architecture in a typical
RPC based architecture. The client system would
request soap messages in terms of parameter list
and return values which will be sent to the server
using remote methods after which the
corresponding response message will be generated
back to the client system. However, within
RESTful architecture the client system will user’s
HTTP requests that are being sent to the server
which performs the calculation process before
generating the HTTP response back to the client
system. The complexity of implementing the
RESTful architecture is significantly less in terms
of components and resources and the coupling
between the server and client system is much more
efficient with our RESTful based web services
implementation. The other key parameters that is
being used for comparison between the RPC and
RESTful architectures is development workload
while designing the cross terminal web applications
that consist of multiple client systems which has
different resources and configurations associated
such as different operating systems like Android,
iOS and also windows and also different storage
and memory configurations. Based on the workload
development procedures, it is clearly identified that
RESTful architecture has reduced workload due to
the data parsing procedures that are being
implemented which justifies the selection of
RESTful architectural model over RPC web
services model in designing the cross-terminal
platform-based system [2].
Webservices design on server
The overall design has been categorised into two
different sections where we will be initially
designing the web services at server side using
different resources and components following
which the design will be extended to the client
application system. After which we are going to
evaluate the overall performance of the design that
has been developed. The entire design has been
developed by the implementation of JSON format
and RESTful architecture over XML and RPC
architecture which has been compared in the
previous sections. The framework that has been
used for development of web services on the server
along with additional components and languages
will be clearly reviewed in this section.

Figure 1- Webservices architectural overview [2]
The above figure gives a clearly overview of the
design that has been used for web services
architectural design. The different RESTful
resources that are used within the server are clearly
highlighted where we can use the resource classes
and resource methods which are further extended to
java spring and hibernate functions that has direct
connection with the database for retrieving the data
and processing it. The Apache CXF server system
has been used as web application server which has
connection extended to the application
programming interface and the resources will be
specified using different Java classes and methods.
The parameters associated with individual classes
and methods will be used in establishing the
connection between the client and server system
where the requests will be generated in different
formats such as hyperlinks, cookie or a binary file
which will be redeployed into the server where the
front annotations are used for generating and
passing the HTTP request using get, post, update or
delete related methods that are being defined in the
RESTful architecture. After successfully
processing the data using different functions and
methods and receiving the data from database, the
corresponding response method will be sent back to
the client application system using different
methods and global configuration files that are
predefined. The integrated development procedures
and corresponding development methods that are
used are highlighted in the above figure where we
can see dependencies between the objects and web
services that are used using object relationship
mapping procedure which is significant component
of the architectural diagram [2].
Design on Client systems
The Overview of client systems design has been
represented in the following figure where we can
see different web pages and mobile applications
that are used for accessing the application
programming interfaces in terms of web pages
which will be used for data exchange. The web
pages will be accessed through the web browsers
where the data will be requested using different
methods that are being followed by the servers the
implementation on mobile devices where the local
API and middleware’s implementation has been
clearly represented in the below figure.
Figure 2- Client-side architectural overview [2]
The mobile apps are being utilised for establishing
the connection between the middleware’s using
Ajax and also the built-in mobile web browsers will
take responsibility in processing and displaying the
web pages along with requested information. The
provided design has feasibility of expanding and
modifying the components as and when required
depending upon the workloads that are being
identified at a given point of time and the kind of
data that is being processed then displayed by the
web services.
The design that has been reviewed in this research
paper has been evaluated against different attributes
such as performance and data values and data
exchange rates which clearly signifies the
importance of Ajax and implementation of JSON
format over traditional XML data-based
implementation. Apart from that, the simpler
interfaces and convenience of expanding the
architectural framework are the key takeaways of
this design which has been implemented using
JSON data format and RESTful web services.
4. Review by Neha - 1943190
Study on REST API Test Model Supporting
Web Service Integration
Earlier, REST has been implemented in a broad
range of Web services. Also, more web services
selected REST-style in their designs patterns, and
this trend is continuing stimulated by the fast
development of mobile enterprises and then rapid
popularization of agile and DevOps, it is hard to
manage GUI testing. Therefore, API is practiced as
a constant and complicated application logic
interface presented outside because the REST
service has features of loose coupling and
uncertainty the testing of REST API will confront
some challenges. It is stateless in the knowledge
that the server does not want to know regarding the
client context. The client can retain a state
independently of the server. It is stateless in the
knowledge that the server does not want to know
regarding the client context which must provide a
uniform interface which is JSON metadata. There
are different methods to transfer data. XML isn’t
widely recommended where usually, JSON
manipulates data as easily on the client-side
particularly in browsers. The client can maintain a
state individually from the server. In practice, this
frequently relies on the standard HTTP cache. In
this paper, focus on a subset of those constraints,
specifically that responses represent resources
through self-descriptive communications. In other
words, when the client performs an HTTP request
to a RESTful service, the service should provide
enough information to enable the client to discover
additional services and information passing on
JSON standard format.
ABOUT REST API TESTING MODEL
Research and analysis showed that a
comprehensive REST API test needs the function
and non-functional test in this function tests of
version adaptability to compatibility with buffering
and connectivity, the accuracy with must need
correctness of response content, the correctness of
response header, and custom validation of support
for each REST API. In this, non-functional tests
demand examining concerted volume is not much.
Manageable performance tests require
maintenance, and system bottlenecks should be
determined by discovering response time and
response size. Furthermore,
The blueprint of the collection + JSON media types
for all RESTful services of the resource is uniquely
recognized by a URL. Any GET/POST/PUT
request method to that URL returns a JSON
response with a status code to acknowledge the
request. To reduce uncertainty for API users when
an error occurs, API gracefully handles and returns
HTTP response codes that indicate what kind of
error occurred to the client.
REST API TEST METHODOLOGY:
Based on the research found important serval
points for API testing methods such as to improve
test coverage and allow the tester to detect errors at
an immediate stage before getting into more
significant problems, it’s more cost-effective, it
should provide stronger security with REST API
are designed to eliminate obvious vulnerabilities, it
should language independent by exchanging data
via json so user can select any language for api
testing, it is highly integral when performing
functional GUI testing. Also, based on various
types of testing models likewise, the Validation
Testing process occurs at the end of the
development cycle to validate whether the API’s
basic parts and functions are correct or not.UI
Testing examines the user interface. UI testing
focuses on the interface experience that ties into the
API to verify the user experience is per the
expected result. Security Testing aim is to cover
any vulnerability, threat or risk within the API so
that malicious attacks can be prevented. Security
testing can identify all possible loopholes and API
weaknesses that can potentially result in a loss of
information, revenue and reputation. Load Testing
Load testing reviews the API performance for a
specific load, by adding the number of user’s
activity into the API. Users can examine how well
the API behaves with a spike of users accessing the
API.
BEYOND THE REST AND JSON
Beyond the standard, REST is not designed to
obtain all possible uses of the Web protocol
standards. RESTful web services are powerful, but
several use cases have originated with APIs that
demand more than REST can offer. Streaming,
real-time communication, and data-heavy
applications have been launched for different types
of APIs. However,
Regression testing is recommended by adjusting
the set of test cases and automatically triggering
function tests by adopting a particular warning
mechanism. There are three trigger modes: timing
trigger, manual trigger, and code update trigger.
(Wenhui, Hu and Yu, Huang and Xueyang, Liu and
Chen, 2017)
3. TEST CASE FOR REST AND JSON:
The assertion is the core segment of a test case and
this test model language is determined and which
solves the obstacle that there's no interface in REST
API test and the problem that the readability of
input and output is poor. In the meantime, the
writing of a large number of testing codes is
omitted. Therefore, it is used for evaluating
whether the output of a test method conforms to
what is expected, including whether the REST API
meets requirements based on whether the output of
the HTTP response, and the verification of the
HTTP response involves several aspects in figure 1.
Also, it is fully functional on the format of data we
are informing the communication in between
request and response of JSON details.
One of the most comprehensive in this space is
Facebook's GraphQL.Designed as a unified query
language for APIs, GraphQL aims to give API
consumers only the data they need, rather than
large payloads that may contain excess content.
Moreover, with the evolution of modern
approaches, patterns, and standards, most of the
integrations will still be RESTful. REST is still a
safe option when building a new API nowadays,
but it may be beyond analyzing possibilities for
example GraphQL, Falcor, or gRPC API.
REST is a kind of data transfer service that is
formed for the architecture of the HTTP protocol. It
allows you to efficiently send and retrieve data
between two various services using XML or JSON.
However, when the REST API is expecting a quick
and precise response from the server then
JavaScript Object Notation (JSON) is one option
that's attracting a lot of attention mainly because
the lightweight approach can make significant
improvements in complex systems of RESTful
API. Nowadays, structuring any web application,
it’s usually good practice to build them using
RESTful architecture with test-driven devolvement
called TDD in which testing will be the most
efficient way to recognize REST flow and
compatibility with RESTful collections and
resources at the very outset. Therefore, REST
testing is an accurate determination because of its
portability and flexibility.
5. Reviewed by Suraj Timilsina-1959410
REST APIs: A Large-Scale Analysis of
Compliance with Principles and Best Practices
REST is an architectural style and a set of guideline
s for developing highly scalable and reliable APIs u
sing HTTP. While the freedom afforded by this dec
ision is one of the reasons for REST's rapid adoptio
n, it is also one of the reasons why everyone unders
tands REST differently and only partially adher-es t
o rules and best practices. In this research, by
looking at the problem from a mobile viewpoint,
and to provide up-to-date information into how
well or poorly the principles and criteria of the
REST architectural style are followed. In the
further section to determine individual HTTP calls
directed at REST API and to characterize the
patterns by using HTTP traffic collected by
telecom Italia which is generate by almost 1 million
subscribers to compare them to guidelines and
principles. The Richardson's maturity model, is also
been discussed which provides an intriguing
approach to think about REST in terms of growing
architectural advantages, to identify different levels
of compliance with the principles.
REST APIs
This division of the research provides the
information about REST and its core principles
along with the rest architectural style which offer a
set of rules for design of networked hypermedia
system that have driven the creation of web. REST
API design principles are in large part the outcome
of Web architecture choices aimed at boosting
scalability and resilience of networked, resource-
oriented systems built on HTTP. The main notion
of Rest API has been employed in study to see if
the theory can be put into practice. Resource
addressability and representations, Uniform
interface, Statelessness, Hypermedia as the engine
of state explain why the term "representational state
transfer" was coined: Each request from the client
to the server carries (transfers) interaction state,
which is encoded inside the representation of the
resource the request refers to.
Rest API best practices
Rest API development practice has been divided
into multiple sections. Resource Modelling,
Resource Identification, Resource Representation
and Operations that used in development. It can
handle different resource including document for
single resource, collection for group of resource
and controller for activities that don’t logically map
to the standard. There are few naming conventions
that are exclusive to rest API: No CRUD name in
the URL, no openness to server-side
implementation technologies and singular noun for
documents, plural noun for collection and verbs
only for controllers. When creating the resource
identifier, the URI format which consist of scheme,
authority, path, query and fragment should be
followed. It has been indicated that during
resources representation the client should indicate it
intended representation using HTTP header
instruction and server should negotiate which
representation to serve at runtime.
Operations: REST APIs should use the HTTP
standard's uniform set of operations (Post, Get, Put,
Delete, Options, and Head) to manage resources
and adhere to their standardized semantics:
For accessing rest compliance Richardson Maturity
Model has been used which provide a mechanism
to explain the various degree of compliance by
using different level of maturity. The further
section of review will look at the level with
compares word that was employed in this study.
 Level 0(Tunnelling): APIs work by
tunnelling requests through a single
endpoint (URL) utilizing a single HTTP
method at this level.
 Level 1(Resources): Instead of using a
single endpoint, the API's functionality is
divided among numerous resources at this
level, increasing the API's addressability
and making it easier to consume. Payload
data or the URL are still used by Level 1
services to identify operations.
 Level 2(HTTP methods): At this level,
APIs make good use of HTTP methods
and status codes for each resource while
still adhering to the uniform interface
principle.
 Level 3(Hypermedia): At this level, APIs
embrace the concept of hypermedia. As a
result, not only may resources be
accessible using a standardized interface,
but their relationships can also be
discovered and explored using appropriate
links.
Mobile internet traffic analysis
In this section, the data includes all HTTP requests
has been captured by the data collector over the
course of one full day of usage, including normal
Web surfing activities. Analysis has done on the
basis of HTTP traffic only and for instance doesn’t
take into account HTTPS traffic, streaming of
audio, video, and other protocol.
Through (Descriptive statistics of the available
dataset characterizing state-of-the-art Mobile
Internet traffic) research, it has been identified that,
the median amount of data supplied is 1463 bytes,
whereas the median amount of data received is
1643 bytes. GET and POST are the most
commonly utilized methods, followed by
CONNECT, HEAD, PUT, OPTION, and DELETE.
Web distributed authoring and versioning have
employed PROFOUND and PROPATCH. Except
for the Source method, which has much larger
values, the statistics are almost the same for all
methods. Use of HTTP methods provides a first
indication of the RESTful APIs' potential
compliance with the REST architectural style
guidelines, which, as we've seen, advocate the use
of not only Get and Post, but also Put, Delete,
Options, Head, and other HTTP methods for the
implementation of what's known as the "uniform
interface" of REST APIs. This research reveals that
certain request techniques are now not just widely
utilized by APIs, but are also considered state-of-
the-art. “Media types” are the generic Web
synonym of “representations” in REST. The two
media types that are of particular interest in this
paper are of course JSON and XML. Keep in mind
that the dataset includes both API and non-API web
traffic. Text/html is shown to be the most popular,
followed by text/jpeg and text/gif. More
remarkable is the fact that data format
application/json is already ranked fourth, while
text/xml is ranked ninth. By examining user agents
from collected datasets, it was discovered that
native apps account for 40.8 percent of traffic,
while mobile and web browsers account for the
remaining 59.2 percent.
REST API analysis by using datasets
HTTP requests that interleave queries for APIs
intended for machine consumption with requests
for Web apps intended for human consumption, it
has been identified that, the media type
application/json has the highest frequency,
followed by text/html, text/xml and others. The
presence of text/HTML, text/CSS and
text/JavaScript indicates that through the same host
names also content oriented toward human agents
(Web sites) is delivered, not only content oriented
toward software agents. Hence, host names are not
good API identifiers in general. it also depends on
the how well the designers of the respective APIs
followed the design principles and best practices.
Research shows that, even though a large portion of
the dataset complies with Level 1, the APIs do not
make proper use of HTTP, The majority of the
dataset, on the other hand, makes effective use of
HTTP and conforms with Level 2, with only a few
hosts meeting Level These findings suggest that
most REST APIs are used to provide CRUD access
to individual resources (Level 1 and 2), rather than
full-fledged APIs that properly interlink resources
and employ hypermedia as the state engine.
Analyses of RESTful design patterns and anti-
patterns have been the subject of recent studies
shed light on design trends and show that even
well-known REST APIs have flaws. However,
rather than a large-scale investigation of API
design techniques, most studies focus on validating
the proposed frameworks. The design and
experiment have been reviewed in this research
paper, clearly shows that while REST APIs have
inextricably become part of modern Web
engineering practice, the gap between theory and
practice remains shockingly large, with only a
fraction of the APIs studied reaching the highest
level of maturity.
6. Review by : Kaladevi Suresh
Student Id: 1956841
Title: “An authentication based scheme
for application using JSON Web
Token” and “Token based
authentication using JSON Web Token
on SIKASIR RESTful Web Service”  access to adding or deleting student details can be
REST and JSON
Integrating applications using simple and uniform
web service. Rest or representation state transfer is
an architectural style that is used to make beautiful
API calls for restful web service application. This
allows easy access of APIs implemented at the
server end via http protocol. Client server
applications developed in any languages for
example java can support rest to implement
uniform web service. Let us consider a student
information application system which has four
APIs like add student details, get student details,
delete existing student details and modify existing
student details. Using rest the APIs are designed in
such a way so that the external user or client can
easily call the restful uniform rest service interface
with less compatibility issues. Any CRUD
operations can be invoked at the client end
associated with the respective http verbs. In rest
resources are transferred between client and server
using xml, YAML or JSON. While JSON is the
most commonly used format, JSON is a simple
light weight data representation format with less
Meta data that can be used to exchange data
between software applications. In this paper we
consider student information application as
example to learn about the implementation of
REST API with JWT token
What is JWT (JSON Web token)?
JSON is JavaScript object notation that is used to
transfer data between client and server to securely
transfer data JWT (JSON web token) was created
and they are generally pronounced as JAWT. Since
JSON is a light weight data format JWT can be sent
through a POST parameter, or inside and http
header and it can be transmitted quickly. This JWT
token send along with the http call has all
information about the entity to avoid querying the
database more than once and the representation of
JWT does not need to call a server to validate the
token. They are basically used for managing
authentication. There are other authorization
mechanisms like session token other than JSON
web token (JWT).
When the response from the server is dynamic
depends on the client then the request from the
client must have the information about who the
client is that needs to be authenticated in the server
end to give appropriate response based on the
client. In our example student information system
done only super user or admin, so API calls to add
student details or delete student details should
include which type of user is trying to access the
APIs along with the other information will be sent
with the http request that will be authorized in the
server end to process the request.
Structure of JWT
The JWT is a string that consists of a header, a
payload and a signature separated by a dots(.) so
for example a typical JWT token looks
likexxxxx.yyyyy.zzzzz.
The in depth breakdown of all the parts are as
follows
Header
They further consists of two parts, type of the token
and the signing algorithm used. The type of token
is JWT and the signing algorithm used can be any
of HMAC SHA256, RSA, etc. The algorithm in the
header represents any hash algorithm for formation
of JWT signature.
Example header: { “typ”:”JWT”, “alg”:HS256”}
The first part of JWT is encoded with Base64Url.
Payload
The second part of the token is payload which
basically the data stored in JWT. They can be about
user for example user name, or email id. These
payload information can be further divided into
registered claims which are also predefined claims
that are recommended to provide useful
information like iss (issuer), exp (Expiration time),
etc. These claims are only three characters long to
make JWT compact. The next is public claims
which can be defined by anyone who is using JWT
at their own will but the public claims need to be
registered in IANA JSON WEB TOKEN Registry
to avoid any collisions. The last is private claims or
custom claims to share information between the
parties.
Example payload: {“sub”: ”123456”, “name”:
”kala”, “admin”: “true”}
This is also encode with Base64Urlto form the
second part of the token.
Signature
The final part of the token is signature. The
signature is created by adding the encoded header,
encoded payload , a secret algorithm specified in
the header and sign that.
Format: token = header + “.” + payload + “.” + “.”
+signature
For example if HMAC SHA256 algorithm is used
then the JWT token looks like
HMACSHA256( base64UrlEncode(header) + "." +
base64UrlEncode(payload), secret).
How JWT works
The basic mechanism for authenticating client in
the server using JWT are as follows:
1. User logs in to the application using
his username and password or using
other sign in options like Google or
Facebook account to login, the
authentication request has details of
like username to authenticate.
2. In the server the user details are
verified by connecting to database
then a JWT token is created with the
retrieved authenticated data from the
user and sent back to client to use the
token for further client requests.
3. The client uses this token to with
request to access resource form the
server
4. The server receives the request and
decodes the JWT token to recognize
the authentic client and then respond
the client with appropriate response.
The main feature of JWT token is that it allows
transition of state to the communication so it
becomes impossible for the client to change the
information contained in the token. There is also a
drawback for this approach as the same JWT token
is used until the user logs off the application.
Student Information System Application
architecture
The journal “Token based authentication using
JSON web token in SIKASIR restful web service”
explains about how the JWT token is implemented
in the SIKASIR web service. I have created a
sample student information system to show the
implementation of the restful APIs like save
student details, retrieve student details, modify
existing student details and delete existing student
details and how client access the APIs using JWT
token. All these API calls can be made from the
client end. Here the rest API calls can be accessed
via postman. This Student information system is
used to demonstrate how rest API works with JWT
token and is built using spring boot and for now I
have not used any database to connect instead all
the data are made static just to show the
implementation of REST API calls and making it
secure with the help of JWT token.
Initially the user logins in with the credentials
username as kaladevi1956841 and password as
password and the rest URL mapping used for this
login is authenticate. The entire rest URL is as
follows:
http://localhost:8080/authenticate
The Http protocol is used local host is the local
server of my system where the spring boot
application is running in the port 8080 and
authenticate is the post mapping and a rest
controller is created on the backend to handle the
rest API call for authentication.
The rest controller checks the given user details
with the existing static data already present in the
code. If the data matches it then proceeds to creates
the JWT token for the user the format for the
generate token is discussed earlier in the paper.
Here I have used HS512 algorithm to create the
JWT token. Once the token is created it is sent
back to the client in the http response body.
Next time when the client wants to access student
details for example in postman a rest URL to get
student information the client has to send the JWT
token in the http request.
The following are the steps involved in student
information system application to access rest APIs
created:
2. In the server the request is handled by
JWT rest controller after the details are
validated JWT token is generated and
shared to the client in response body.
3. The client adds the JWT token in the
header of the request i.e. in postman in the
authentication tab choose bearer token and
give the JWT token details to access other
rest API calls like get student details.
4. In the server student details controller
handles the request and responses the
client with appropriate responses.
The Sample Student information system
application is created to implement the JWT
token based rest API calls. The project is
uploaded in GitHub and I have shared the link
of the project in the additional submissions I
have also include a document on how to test
the rest API calls using the JWT token.
There are many standard security approaches
that works well with rest API but JWT is better
among all as the JWT’s main strength is
handling user authentication in a stateless
manner that is scalable. The user roles and
permissions in the token itself created huge
benefits in distributed systems architecture as
the server that issues token does not have
access over the authentication data source.

1. Through postman REST URL

http://localhost:8080/authenticate is
entered and user details like username and
password are mentioned in the body of the
http post request.

7. Discussions

The overall findings of all the individual research performed are discussed in this section. The key findings of
overall research will be discussed between all the team members and the highlighted points will be showcased in
this section.

The first review of the journal Knowledge graphs construction using RESTful API and JSON Schema by
Vamshi discusses about existing frameworks associated with collaboration spotting and corresponding
procedures where heterogeneous data will be collected and organised into a structural format following which
we have reviewed the detailed architecture which has been proposed using JSON framework that allows data
exchange between different platforms related application layer. We have also reviewed different processes and
models associated with this and corresponding use cases used for configuration of database models. This review
clearly highlights the effectiveness or proposed architectural model specifically for metadata schema that helps
in creation of knowledge graphs.

The cross-terminal web system design section by Vignesh primarily discusses about comparison with XML and
JSON to understand different parameters and parsing process which clearly highlights the data organising
process and key value combinations used for storing the information. We have also reviewed and compared
RPCful architecture and restful architecture to differentiate services and also client system model which helps to
understand the significant differences in both models and further we have started on creating a web services
design both on server side and client side individually by following the recommended architectural models
where we have used JSON and restful services instead of XML and RPC architecture which clearly showcased
significance and improvements in overall services delivery between client and server systems.

The subsequent review of the study on REST API Test Model Supporting Web Service Integration by Neha

Suraj’s review on A Large-Scale Analysis of Compliance with Principles and Best Practices discusses about
how using a full-fledged API that properly interlinked resource and hypermedia as the state engine the most in
practice are individual resource (Level 1 and Level2). The findings of this study reveal that even well-known
APIs aren't ideal. While the distance between theory and practice continues to widen. In 2021 some prediction
can be made for future of API as, with HTTP3 it is going to have better API experience in mobile device, we
can use event driven API to generate new business models, using micro service in API It allows developers to
define independent, loosely coupled pieces of code that are linked to API endpoints.

The final review made by Kaladevi Suresh on the authentication based scheme for application using JSON Web
Token the implementation of the same in a sample student information system application discusses about how
the rest API calls can be secured with JWT, the format of JWT which is classified into three parts, header,
payload and signature and how they are encoded using base64URL technique. The implementation of JWT
token has been explained with a sample student information system that has been created. This student
Information system is a spring boot application that has a JWT rest controller to handle the rest API calls to
create a JWT token by authorising the request parameters and updates the same response body with the JWT
token. The next request to the server are made by including the generated token in the header of the http request
so each request is validated and appropriate responses are provided based on the request.

8. Conclusion

To conclude all the journals discussed in this paper reviews various aspects of REST API like the how
a knowledge graph can be constructed with REST api , cross terminal web system is designed, how to
test the implemented web service using rest api, its principle and constraints and finally sample
application to implement the JWT token which depicts how the server interacts with the client by
transferring data securely using JWT for a student information system. This paper further discusses
about the drawbacks about the api the main drawback is the client has to receive the entire payload
even when the requested information by the client is very minimal and what is beyond the rest api the
usage of the graphql which is a unified query language api unlike rest api the graphql only provides the
client with the information requested that reducing the large payload that contains extra content. The
JWT token is discussed which is used to securely transfer data between two parties which is a light
weight and simple implementation and discuss the format of JWT how it works and also how its usage
is benefits the distributed system architecture.
 9. REFERENCES

[1] . A. A. Frozza, R. dos Mello, and F. de Costa, “An approach for schema extraction of
JSON and extended JSON document collections,” 2018 IEEE International
Conference on Information Reuse and Integration (IRI), 2018.
[2] . A. Agocs and J.-M. L. Goff, “A web service based on restful API and JSON
schema/JSON meta schema to construct knowledge graphs,” 2018 International
Conference on Computer, Information and Telecommunication Systems (CITS),
2018.
[3] Niu, Z., Yang, C. & Zhang, Y., 2014. “A design of cross-terminal web system based
on JSON and rest”. 2014 IEEE 5th International Conference on Software Engineering
and Service Science.
[4] Späth, P., 2019. Building single-page web applications with rest and JSON.
Beginning Jakarta EE, pp.133–163.
[5] H. Wenhui, H. Yu, L. Xueyang and X. Chen, "Study on REST API Test Model
Supporting Web Service Integration," 2017 ieee 3rd international conference on big
data security on cloud (bigdatasecurity), ieee international conference on high
performance and smart computing (hpsc), and ieee international conference on
intelligent data and security (ids), 2017. https://ieeexplore.ieee.org/stamp/stamp.jsp?
tp=&arnumber=7980330&isnumber=7980294
[6] B. Barnard and M. Di Pierro, "Extending Collection+JSON and Automatic CRUD
Interfaces," 2014 IEEE 17th International Conference on Computational Science and
Engineering, 2014
[7] Rodríguez C. et al. (2016) “REST APIs: A Large-Scale Analysis of Compliance with
Principles and Best Practices”. In: Bozzon A., Cudre-Maroux P., Pautasso C. (eds)
Web Engineering. ICWE 2016. Lecture Notes in Computer Science, vol 9671.
Springer, Cham. https://doi.org/10.1007/978-3-319-38791-8_2

[8] S. Ahmed and Q. Mahmood, "An authentication based scheme for applications using
JSON web token," 2019 22nd International Multitopic Conference (INMIC), 2019, pp.
1-6, doi: 10.1109/INMIC48123.2019.9022766.

[9] M. Haekal and Eliyani, "Token-based authentication using JSON Web Token on
SIKASIR RESTful Web Service," 2016 International Conference on Informatics and
Computing (ICIC), 2016, pp. 175-179, doi: 10.1109/IAC.2016.7905711.

10. Appendix

Knowledge graphs construction using RESTful API and JSON Schema

Abstract—Data visualisation assists domain experts in understanding their data and helps them make critical
decisions. Enhancing their cognitive insight essentially relies on the capability of combining domain-specific
semantic information with concepts extracted out of the data and visualizing the resulting networks. Data
scientists have the challenge of providing tools able to handle the overall network lifecycle. In this paper, we
present how the combination of two powerful technologies namely the REST architecture style and JSON
Schema/JSON Meta Schema enable data scientists to use a RESTful web service that permits the construction of
knowledge graphs, one of the preferred representations of large and semantically rich networks.

Designing a Cross-terminal Web System Based on JSON and REST

Abstract—a cross-terminal web system refers to a web system which can be accessed through various terminal
platforms, including the web browsers on personal computers, the mobile applications on smart phones and so
on. Traditional design of such a system usually uses XML data format and RPCful web services. There are some
issues lying in this design such as the low efficiency of data exchange, the complex interfaces, and the difficulty
in modifying and expanding. Therefore, it cannot meet the demands of designing a cross-terminal case well. In
order to solve the issues, a system design based on JSON data format and RESTful web services is presented,
which has high efficiency of data exchange, simple interfaces and convenience for modification and expansion.
The design also provides good support for the cross-terminal case.

Study on REST API Test Model Supporting Web Service Integration

ABSTRACT- REST is to define a practice environment for connectors, components, and data elements and the
client and server work individually with a clear separation of requests and responses that continue to be
exchanged to communicate. When the client sends a request to the server via the endpoint and the API server
processes the request which performs the required operation and sends an acknowledgment back. This response
is usually in the form of an HTTP status code and a JSON object. This report will reflect upon the study on
REST API testing model with supporting web service integration and extending collection of json and automatic
crud interfaces of REST API.

REST APIs: A Large-Scale Analysis of Compliance with Principles and Best Practices

Abstract - Quickly and dominantly, REST API’s have spread over the web and percolated into modern software
development practice, especially in the mobile internet where they conveniently enable offloading data and
communications onto cloud service. We analyse more than 78 GB of HTTP traffic collected by Italy’s biggest
mobile internet provider over one full day and study how big the trend is in practice, how it changed the traffic
that is generated by applications and how REST APIs are implemented in practice. The analysis provides
insight into the compliance of state-of-the-art APIs with theoretical web engineering principles and guidelines,
Knowledge that affect how application should be developed to be scalable and robust. The perspective is that of
the mobile internet.

An authentication based scheme for application using JSON Web Token” and “Token based authentication
using JSON Web Token on SIKASIR RESTful Web Service

Abstract- REST APIs are great as they logically simple and don’t keep complex states in memory, they deal with
resources making their entire business logic cohesive. Due to the nature and mechanics behind REST APIs,
securing them is not always straightforward. In this paper, I have discussed about one of the very powerful yet
simple way you can achieve secured data transfer between two parties using JSON Web Tokens (JWT). The
paper discusses about the format and how the JWT can be used and also a simple implementation of JWT using
a student information system a spring boot application service which has JWT controller to validate the
authorisation of the users login and create the JWT token for the verified uses and also a student controller to
perform basic crud operations on the student object.