SlideShare a Scribd company logo
REST & RESTful WEB
SERVICES
In a Nutshell
 REST is about resources and how to represent resources in
different ways.
 REST is about client-server communication.
 REST is about how to manipulate resources.
 REST offers a simple, interoperable and flexible way of
writing web services that can be very different from other
techniques.
 Comes from Roy Fielding’s Thesis study.
REST is NOT!
 A protocol.
 A standard.
 A replacement for SOAP.
REST
 Representational State Transfer
 Architectural style (technically not a standard)
 Idea: a network of web pages where the client progresses
through an application by selecting links
 When client traverses link, accesses new resource (i.e.,
transfers state)
 Uses existing standards, e.g., HTTP
 REST is an architecture all about the Client-Server
communication.
An Architectural Style
 REST is the architecture of the Web as it works today and,
so it is already used in the web!
 It is an software architectural model which is used to
describe distributed systems like WWW (World Wide
Web).
 It has been developed in parallel with HTTP protocol.
THE WEB
REST
 Client requests a specific resource from the server.
 The server responds to that request by delivering the
requested resource.
 Server does not have any information about any client.
 So, there is no difference between the two requests of
the same client.
 A model which the representations of the resources are
transferred between the client and the server.
 The Web as we know is already in this form!
Resources
 Resources are just consistent mappings from an identifier
[such as a URL path] to some set of views on server-side
state.
 Every resource must be uniquely addressable via a URI.
 “If one view doesn’t suit your needs, then feel free to
create a different resource that provides a better view. ”
 “These views need not have anything to do with how the
information is stored on the server … They just need to be
understandable (and actionable) by the recipient.”
Roy T. Fielding
Requests & Responses
 REQUEST
GET /news/ HTTP/1.1
Host: example.org
Accept-Encoding: compress, gzip
User-Agent: Python-httplib2
Here is a GET request to «http://example.org/news/»
Method = GET
Requests & Responses
 And here is the response…
 RESPONSE
HTTP/1.1 200 Ok
Date: Thu, 07 Aug 2008 15:06:24 GMT
Server: Apache
ETag: "85a1b765e8c01dbf872651d7a5"
Content-Type: text/html
Cache-Control: max-age=3600
<!DOCTYPE HTML>
...
Requests & Responses
 The request is to a resource identified by a URI
(URI = Unified Resource Identifier).
 In this case, the resource is «http://example.org/news/»
 Resources, or addressability is very important.
 Every resource is URL-addressable.
 To change system state, simply change a resource.
URI Examples
 http://localhost:9999/restapi/books
 GET – get all books
 POST – add a new book
 http://localhost:9999/restapi/books/{id}
 GET – get the book whose id is provided
 POST – update the book whose id is provided
 DELETE – delete the book whose id is provided
REST Characteristics
 Resources: Application state and functionality are abstracted into resources.
 URI: Every resource is uniquely addressable using URIs.
 Uniform Interface: All resources share a uniform
interface for the transfer of state between client and resource, consisting of
• Methods: Use only HTTP methods such as GET, PUT, POST, DELETE, HEAD
• Representation
 Protocol (The constraints and the principles)
 Client-Server
 Stateless
 Cacheable
 Layered
HTTP Methods
 GET – safe, idempotent, cacheable
 PUT - idempotent
 POST
 DELETE - idempotent
 HEAD
 OPTIONS
CRUD Operations Mapped to HTTP
Methods in RESTful Web Services
OPERATION HTTP METHOD
Create POST
Read GET
Update PUT or POST
Delete DELETE
RESTful Web Services
 RESTful web services are web services which are REST based.
 Stateless & cacheable.
 Uses URI & HTTP methods.
 Frequently used with SOA projects.
 Quiet light, extensible and simple services.
 The reason behind the popularity of REST is that the
applications we use are browser-based nowadays and top it all,
REST is built on HTTP.
 Main idea: Providing the communication between client and
server over HTTP protocol rather than other complex
architectures like SOAP and RPC etc.
RESTful Web Services
 You can do anything you already do with normal web services.
 No severe restrictions on how the architectural model will be and
what properties it will have.
 Models like SOAP have severe rules, REST does not.
 There are lots of frameworks to develop RESTful web services on
platforms like C# and Java, but you can write one easily using some
standard libraries.
 Inspite of the low bandwidth, large data have been transfered with
methods even inflating the size of the data, like XML with SOAP. Why?
 Nowadays, the bandwidth is amazingly large, but we still use JSON
and it shrinks the size of our data.
RESTful Web Services
 Platform independent.
 Language independent.
 Work on HTTP protocol.
 Flexible and easily extendible.
 They also have some constraints or principles.
 Client-Server
 Stateless
 Cacheable
 Uniform Interface
 Layered System
 Code on Demand
Client-Server
 Seperation of concerns.
 Client and server are independent from eachother.
 Client doesn’t know anything about the resource which is kept in the server.
 Server responds as long as the right requests come in.
 Goal: Platform independency and to improve scalability.
Stateless
 Each request is independent from other requests.
 No client session data or any context stored on the server.
 Every request from client stores the required information, so that
the server can respond.
 If there are needs for session-specific data, it should be held and
maintained by the client and transferred to the server with each
request as needed.
 A service layer which doesn’t have to maintain client sessions is
much easier to scale.
 Of course there may be cumbersome situations:
 The client must load the required information to every request. And
this increases the network traffic.
 Server might be loaded with heavy work of «validation» of requests.
Scalability
Cacheable
 HTTP responses must be cacheable by the clients.
 Important for performance.
 If a new request for the resources comes within a while, then the cached
response will be returned.
Uniform Interface
 All resources are accessed with a generic interface (HTTP-based).
 This makes it easier to manage the communication.
 By the help of a uniform interface, client and server evolve
independently from eachother.
 E.g. LEGO; eventhough there are different shaped pieces, there are only
a few ways to pair up these pieces.
Layered System
 There can be many intermediaries between you and the server
you are connecting to.
 Actually, a client does not know if it is connected to the last
server or an intermediary server.
 Intermediaries may improve performance by caching and
message passing.
 Intermediary servers can increase scalability by load-balancing
and can force clients to form some sort of security policies.
 This structure can be used when encapsulation is needed.
Code on Demand
 Servers can send some kind of executable scripts to the
client-side in order to increase or change the functionality
on the client side.
 This may cause low visibility, so it is the only optional
constraint.
 EXAMPLE
...
<head>
<script src="utility.js"
type="text/javascript">
</script>
...
more
 If a service does not include all constraints out of «Code
on Demand», it is not a RESTful web service.
 The most epic constraint is «Stateless».
What REST actually aims for?
 Scalability
 Simplicity
 Modifiability
 Useability
 Portability
 Reliability
Benefits
Network Performance
 Efficiency
 Scalability
 User Perceived
Performance
Other Benefits
 Simplicity
 Evolvability
 Reuseability
 Visibility
 Extensibility
 Configuration
 Customizability
Benefits ctd.
 HTTP is efficient because of all those caches, your request may not have to reach
all the way back to the origin server.
 Scalability comes from many areas. The use of layers allows you to distribute traffic
among a large set of origin servers based on method, URI or content-type, or any
other visible control data or meta-data in the request headers.
 Caching also helps scalability as it reduces the actual number of requests that hit
the origin server.
 Statelessness allows requests to be routed through different gateways and proxies,
thus avoiding introducing bottlenecks, allowing more intermediaries to be added as
needed. [Scalability]
Will REST Replace Other Technologies ?
 There is actually an untold story that both technologies can
be mixed and matched. REST is very easy to understand and
is extremely approachable, but does lack standards and is
considered an architectural approach. In comparison, SOAP
is an industry standard with a well-defined protocol and a
set of well-established rules to be implemented, and it has
been used in systems both big and small.
REST vs SOAP
 SOAP is a XML-based message protocol, while REST is an architectural style.
 SOAP uses WSDL for communication between consumer and provider, whereas
REST just uses XML or JSON to send and receive data.
 SOAP invokes services by calling RPC method, REST just simply calls services
via URL path.
 SOAP doesn't return human readable result, whilst REST result is readable
with is just plain XML or JSON.
 SOAP is not just over HTTP, it also uses other protocols such as SMTP, FTP, etc,
REST is over only HTTP.
SOAP uses WSDL for communication between
consumer and provider, whereas REST just uses XML
or JSON to send and receive data.
 WSDL defines contract between client and service and is static by its
nature. In case of REST contract is somewhat complicated and is
defined by HTTP, URI, Media Formats and Application Specific
Coordination Protocol. It's highly dynamic unlike WSDL.
Performance is broad topic!-1
 If you mean the load of the server, REST has a bit better performance because
it bears minimal overhead on top of HTTP. Usually SOAP brings with it a stack
of different (generated) handlers and parsers. Anyway, the performance
difference itself is not that big, but RESTful service is more easy to scale up
since you don't have any server side sessions.
 If you mean the performance of the network (i.e. bandwidth), REST has much
better performance. Basically, it's just HTTP. No overhead. So, if your service
runs on top of HTTP anyway, you can't get much leaner than REST.
Furthermore if you encode your representations in JSON (as opposed to XML),
you'll save many more bytes.
 In short, I would say 'yes', you'll be more performant with REST. Also, it (in my
opinion) will make your interface easier to consume for your clients. So, not
only your server becomes leaner but the client too.
Performance is broad topic!-2
*However, couple of things to consider!
 RESTful interfaces tend to be a bit more "chatty", so depending on your
domain and how you design your resources, you may end up doing more HTTP
requests.
 SOAP has a very wide tool support. For example, consultants love it because
they can use tools to define the interface and generate the WSDL file and
developers love it because they can use another set of tools to generate all
the networking code from that WSDL file. Moreover, XML as representation
has schemas and validators, which in some cases may be a key issue. (JSON
and REST do have similar stuff coming but the tool support is far behind)
Complements or Competitors ?
 There is some competition between proponents of each
approach.
 Yet both have value.
 The challenge is to determine when to use each one !
So the areas that REST works really well
are:
 Limited bandwidth and resources; remember the return structure is really in
any format (developer defined). Plus, any browser can be used because the
REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again,
remember that REST can also use the XMLHttpRequest object that most
modern browsers support today, which adds an extra bonus of AJAX.
 Totally stateless operations; if an operation needs to be continued, then
REST is not the best approach and SOAP may fit it better. However, if you
need stateless CRUD (Create, Read, Update, and Delete) operations, then
REST is it.
 Caching situations; if the information can be cached because of the totally
stateless operation of the REST approach, this is perfect.
So if you have the following then SOAP is
a great solution:
 Asynchronous processing and invocation; if your application needs a
guaranteed level of reliability and security then SOAP 1.2 offers additional
standards to ensure this type of operation. Things like WSRM – WS-Reliable
Messaging.
 Formal contracts; if both sides (provider and consumer) have to agree on the
exchange format then SOAP 1.2 gives the rigid specifications for this type of
interaction.
 Stateful operations; if the application needs contextual information and
conversational state management then SOAP 1.2 has the additional
specification in the WS* structure to support those things (Security,
Transactions, Coordination, etc). Comparatively, the REST approach would
make the developers build this custom plumbing.
THANK YOU FOR YOUR PATIENCE AND
LISTENING!

More Related Content

What's hot

Web services SOAP
Web services SOAPWeb services SOAP
Web services SOAP
princeirfancivil
 
Rest API Security
Rest API SecurityRest API Security
Rest API Security
Stormpath
 
Introduction to the Web API
Introduction to the Web APIIntroduction to the Web API
Introduction to the Web API
Brad Genereaux
 
HTTP request and response
HTTP request and responseHTTP request and response
HTTP request and response
Sahil Agarwal
 
WSDL
WSDLWSDL
Java collections concept
Java collections conceptJava collections concept
Java collections concept
kumar gaurav
 
Json
JsonJson
Api presentation
Api presentationApi presentation
Api presentation
Tiago Cardoso
 
Rest webservice ppt
Rest webservice pptRest webservice ppt
Rest webservice ppt
sinhatanay
 
[Final] ReactJS presentation
[Final] ReactJS presentation[Final] ReactJS presentation
[Final] ReactJS presentation
洪 鹏发
 
Web api
Web apiWeb api
Servlet and servlet life cycle
Servlet and servlet life cycleServlet and servlet life cycle
Servlet and servlet life cycle
Dhruvin Nakrani
 
Introduction to APIs (Application Programming Interface)
Introduction to APIs (Application Programming Interface) Introduction to APIs (Application Programming Interface)
Introduction to APIs (Application Programming Interface)
Vibhawa Nirmal
 
What is REST API? REST API Concepts and Examples | Edureka
What is REST API? REST API Concepts and Examples | EdurekaWhat is REST API? REST API Concepts and Examples | Edureka
What is REST API? REST API Concepts and Examples | Edureka
Edureka!
 
Servlets
ServletsServlets
Servlets
ServletsServlets
Servlets
ZainabNoorGul
 
Webservices
WebservicesWebservices
Webservices
Gerard Sylvester
 
HTTP Request and Response Structure
HTTP Request and Response StructureHTTP Request and Response Structure
HTTP Request and Response Structure
BhagyashreeGajera1
 
Https presentation
Https presentationHttps presentation
Https presentation
patel jatin
 
An Overview of Web Services: SOAP and REST
An Overview of Web Services: SOAP and REST An Overview of Web Services: SOAP and REST
An Overview of Web Services: SOAP and REST
Ram Awadh Prasad, PMP
 

What's hot (20)

Web services SOAP
Web services SOAPWeb services SOAP
Web services SOAP
 
Rest API Security
Rest API SecurityRest API Security
Rest API Security
 
Introduction to the Web API
Introduction to the Web APIIntroduction to the Web API
Introduction to the Web API
 
HTTP request and response
HTTP request and responseHTTP request and response
HTTP request and response
 
WSDL
WSDLWSDL
WSDL
 
Java collections concept
Java collections conceptJava collections concept
Java collections concept
 
Json
JsonJson
Json
 
Api presentation
Api presentationApi presentation
Api presentation
 
Rest webservice ppt
Rest webservice pptRest webservice ppt
Rest webservice ppt
 
[Final] ReactJS presentation
[Final] ReactJS presentation[Final] ReactJS presentation
[Final] ReactJS presentation
 
Web api
Web apiWeb api
Web api
 
Servlet and servlet life cycle
Servlet and servlet life cycleServlet and servlet life cycle
Servlet and servlet life cycle
 
Introduction to APIs (Application Programming Interface)
Introduction to APIs (Application Programming Interface) Introduction to APIs (Application Programming Interface)
Introduction to APIs (Application Programming Interface)
 
What is REST API? REST API Concepts and Examples | Edureka
What is REST API? REST API Concepts and Examples | EdurekaWhat is REST API? REST API Concepts and Examples | Edureka
What is REST API? REST API Concepts and Examples | Edureka
 
Servlets
ServletsServlets
Servlets
 
Servlets
ServletsServlets
Servlets
 
Webservices
WebservicesWebservices
Webservices
 
HTTP Request and Response Structure
HTTP Request and Response StructureHTTP Request and Response Structure
HTTP Request and Response Structure
 
Https presentation
Https presentationHttps presentation
Https presentation
 
An Overview of Web Services: SOAP and REST
An Overview of Web Services: SOAP and REST An Overview of Web Services: SOAP and REST
An Overview of Web Services: SOAP and REST
 

Viewers also liked

Introduction To REST
Introduction To RESTIntroduction To REST
Introduction To REST
Bhavya Siddappa
 
Rest and the hypermedia constraint
Rest and the hypermedia constraintRest and the hypermedia constraint
Rest and the hypermedia constraint
Inviqa
 
Learn REST in 18 Slides
Learn REST in 18 SlidesLearn REST in 18 Slides
Learn REST in 18 Slides
Suraj Gupta
 
RESTful services
RESTful servicesRESTful services
RESTful services
gouthamrv
 
The Internet as Web Services: introduction to ReST
The Internet as Web Services: introduction to ReSTThe Internet as Web Services: introduction to ReST
The Internet as Web Services: introduction to ReST
Bruno Kessler Foundation
 
HATEOAS 101 - Opinionated Introduction to a REST API Style
HATEOAS 101 - Opinionated Introduction to a REST API StyleHATEOAS 101 - Opinionated Introduction to a REST API Style
HATEOAS 101 - Opinionated Introduction to a REST API Style
Apigee | Google Cloud
 
REST Presentation
REST PresentationREST Presentation
REST Presentation
Alexandros Marinos
 

Viewers also liked (7)

Introduction To REST
Introduction To RESTIntroduction To REST
Introduction To REST
 
Rest and the hypermedia constraint
Rest and the hypermedia constraintRest and the hypermedia constraint
Rest and the hypermedia constraint
 
Learn REST in 18 Slides
Learn REST in 18 SlidesLearn REST in 18 Slides
Learn REST in 18 Slides
 
RESTful services
RESTful servicesRESTful services
RESTful services
 
The Internet as Web Services: introduction to ReST
The Internet as Web Services: introduction to ReSTThe Internet as Web Services: introduction to ReST
The Internet as Web Services: introduction to ReST
 
HATEOAS 101 - Opinionated Introduction to a REST API Style
HATEOAS 101 - Opinionated Introduction to a REST API StyleHATEOAS 101 - Opinionated Introduction to a REST API Style
HATEOAS 101 - Opinionated Introduction to a REST API Style
 
REST Presentation
REST PresentationREST Presentation
REST Presentation
 

Similar to REST & RESTful Web Services

REST Introduction.ppt
REST Introduction.pptREST Introduction.ppt
REST Introduction.ppt
KGSCSEPSGCT
 
Rest surekha
Rest surekhaRest surekha
Rest surekha
Surekha Achanta
 
Unit 2
Unit 2Unit 2
Unit 2
Ravi Kumar
 
Mini-Training: Let's have a rest
Mini-Training: Let's have a restMini-Training: Let's have a rest
Mini-Training: Let's have a rest
Betclic Everest Group Tech Team
 
Restful web services by Sreeni Inturi
Restful web services by Sreeni InturiRestful web services by Sreeni Inturi
Restful web services by Sreeni Inturi
Sreeni I
 
Rest api best practices – comprehensive handbook
Rest api best practices – comprehensive handbookRest api best practices – comprehensive handbook
Rest api best practices – comprehensive handbook
Katy Slemon
 
Lab7 paper
Lab7 paperLab7 paper
Modern REST API design principles and rules.pdf
Modern REST API design principles and rules.pdfModern REST API design principles and rules.pdf
Modern REST API design principles and rules.pdf
Aparna Sharma
 
Restful web services
Restful web servicesRestful web services
Restful web services
MD Sayem Ahmed
 
Separating REST Facts from Fallacies
Separating REST Facts from FallaciesSeparating REST Facts from Fallacies
Separating REST Facts from Fallacies
Alan Dean
 
Modern REST API design principles and rules.pdf
Modern REST API design principles and rules.pdfModern REST API design principles and rules.pdf
Modern REST API design principles and rules.pdf
Aparna Sharma
 
Restful web-services
Restful web-servicesRestful web-services
Restful web-services
rporwal
 
Overview of Rest Service and ASP.NET WEB API
Overview of Rest Service and ASP.NET WEB APIOverview of Rest Service and ASP.NET WEB API
Overview of Rest Service and ASP.NET WEB API
Pankaj Bajaj
 
What are restful web services?
What are restful web services?What are restful web services?
What are restful web services?
Aparna Sharma
 
RESTful APIs
RESTful APIsRESTful APIs
RESTful APIs
Adi Challa
 
Web Programming
Web ProgrammingWeb Programming
Web Programming
VijayapriyaP1
 
REST & SOAP.pptx
REST & SOAP.pptxREST & SOAP.pptx
REST & SOAP.pptx
ZawLwinTun2
 
REST & RESTful APIs: The State of Confusion
REST & RESTful APIs: The State of ConfusionREST & RESTful APIs: The State of Confusion
REST & RESTful APIs: The State of Confusion
Glenn Antoine
 
C# REST API
C# REST APIC# REST API
C# REST API
Simplilearn
 
Apitesting.pptx
Apitesting.pptxApitesting.pptx
Apitesting.pptx
NamanVerma88
 

Similar to REST & RESTful Web Services (20)

REST Introduction.ppt
REST Introduction.pptREST Introduction.ppt
REST Introduction.ppt
 
Rest surekha
Rest surekhaRest surekha
Rest surekha
 
Unit 2
Unit 2Unit 2
Unit 2
 
Mini-Training: Let's have a rest
Mini-Training: Let's have a restMini-Training: Let's have a rest
Mini-Training: Let's have a rest
 
Restful web services by Sreeni Inturi
Restful web services by Sreeni InturiRestful web services by Sreeni Inturi
Restful web services by Sreeni Inturi
 
Rest api best practices – comprehensive handbook
Rest api best practices – comprehensive handbookRest api best practices – comprehensive handbook
Rest api best practices – comprehensive handbook
 
Lab7 paper
Lab7 paperLab7 paper
Lab7 paper
 
Modern REST API design principles and rules.pdf
Modern REST API design principles and rules.pdfModern REST API design principles and rules.pdf
Modern REST API design principles and rules.pdf
 
Restful web services
Restful web servicesRestful web services
Restful web services
 
Separating REST Facts from Fallacies
Separating REST Facts from FallaciesSeparating REST Facts from Fallacies
Separating REST Facts from Fallacies
 
Modern REST API design principles and rules.pdf
Modern REST API design principles and rules.pdfModern REST API design principles and rules.pdf
Modern REST API design principles and rules.pdf
 
Restful web-services
Restful web-servicesRestful web-services
Restful web-services
 
Overview of Rest Service and ASP.NET WEB API
Overview of Rest Service and ASP.NET WEB APIOverview of Rest Service and ASP.NET WEB API
Overview of Rest Service and ASP.NET WEB API
 
What are restful web services?
What are restful web services?What are restful web services?
What are restful web services?
 
RESTful APIs
RESTful APIsRESTful APIs
RESTful APIs
 
Web Programming
Web ProgrammingWeb Programming
Web Programming
 
REST & SOAP.pptx
REST & SOAP.pptxREST & SOAP.pptx
REST & SOAP.pptx
 
REST & RESTful APIs: The State of Confusion
REST & RESTful APIs: The State of ConfusionREST & RESTful APIs: The State of Confusion
REST & RESTful APIs: The State of Confusion
 
C# REST API
C# REST APIC# REST API
C# REST API
 
Apitesting.pptx
Apitesting.pptxApitesting.pptx
Apitesting.pptx
 

Recently uploaded

Generating privacy-protected synthetic data using Secludy and Milvus
Generating privacy-protected synthetic data using Secludy and MilvusGenerating privacy-protected synthetic data using Secludy and Milvus
Generating privacy-protected synthetic data using Secludy and Milvus
Zilliz
 
Astute Business Solutions | Oracle Cloud Partner |
Astute Business Solutions | Oracle Cloud Partner |Astute Business Solutions | Oracle Cloud Partner |
Astute Business Solutions | Oracle Cloud Partner |
AstuteBusiness
 
GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)
Javier Junquera
 
Crafting Excellence: A Comprehensive Guide to iOS Mobile App Development Serv...
Crafting Excellence: A Comprehensive Guide to iOS Mobile App Development Serv...Crafting Excellence: A Comprehensive Guide to iOS Mobile App Development Serv...
Crafting Excellence: A Comprehensive Guide to iOS Mobile App Development Serv...
Pitangent Analytics & Technology Solutions Pvt. Ltd
 
Principle of conventional tomography-Bibash Shahi ppt..pptx
Principle of conventional tomography-Bibash Shahi ppt..pptxPrinciple of conventional tomography-Bibash Shahi ppt..pptx
Principle of conventional tomography-Bibash Shahi ppt..pptx
BibashShahi
 
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-EfficiencyFreshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
ScyllaDB
 
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
saastr
 
Introduction of Cybersecurity with OSS at Code Europe 2024
Introduction of Cybersecurity with OSS  at Code Europe 2024Introduction of Cybersecurity with OSS  at Code Europe 2024
Introduction of Cybersecurity with OSS at Code Europe 2024
Hiroshi SHIBATA
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
Jason Packer
 
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
Edge AI and Vision Alliance
 
Leveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and StandardsLeveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and Standards
Neo4j
 
Choosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptxChoosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptx
Brandon Minnick, MBA
 
Essentials of Automations: Exploring Attributes & Automation Parameters
Essentials of Automations: Exploring Attributes & Automation ParametersEssentials of Automations: Exploring Attributes & Automation Parameters
Essentials of Automations: Exploring Attributes & Automation Parameters
Safe Software
 
Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
ssuserfac0301
 
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUHCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
panagenda
 
What is an RPA CoE? Session 1 – CoE Vision
What is an RPA CoE?  Session 1 – CoE VisionWhat is an RPA CoE?  Session 1 – CoE Vision
What is an RPA CoE? Session 1 – CoE Vision
DianaGray10
 
Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup SlidesProgramming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
Zilliz
 
The Microsoft 365 Migration Tutorial For Beginner.pptx
The Microsoft 365 Migration Tutorial For Beginner.pptxThe Microsoft 365 Migration Tutorial For Beginner.pptx
The Microsoft 365 Migration Tutorial For Beginner.pptx
operationspcvita
 
Fueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte WebinarFueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte Webinar
Zilliz
 

Recently uploaded (20)

Generating privacy-protected synthetic data using Secludy and Milvus
Generating privacy-protected synthetic data using Secludy and MilvusGenerating privacy-protected synthetic data using Secludy and Milvus
Generating privacy-protected synthetic data using Secludy and Milvus
 
Astute Business Solutions | Oracle Cloud Partner |
Astute Business Solutions | Oracle Cloud Partner |Astute Business Solutions | Oracle Cloud Partner |
Astute Business Solutions | Oracle Cloud Partner |
 
GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)GNSS spoofing via SDR (Criptored Talks 2024)
GNSS spoofing via SDR (Criptored Talks 2024)
 
Crafting Excellence: A Comprehensive Guide to iOS Mobile App Development Serv...
Crafting Excellence: A Comprehensive Guide to iOS Mobile App Development Serv...Crafting Excellence: A Comprehensive Guide to iOS Mobile App Development Serv...
Crafting Excellence: A Comprehensive Guide to iOS Mobile App Development Serv...
 
Principle of conventional tomography-Bibash Shahi ppt..pptx
Principle of conventional tomography-Bibash Shahi ppt..pptxPrinciple of conventional tomography-Bibash Shahi ppt..pptx
Principle of conventional tomography-Bibash Shahi ppt..pptx
 
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-EfficiencyFreshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
 
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
 
Introduction of Cybersecurity with OSS at Code Europe 2024
Introduction of Cybersecurity with OSS  at Code Europe 2024Introduction of Cybersecurity with OSS  at Code Europe 2024
Introduction of Cybersecurity with OSS at Code Europe 2024
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
 
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
“Temporal Event Neural Networks: A More Efficient Alternative to the Transfor...
 
Artificial Intelligence and Electronic Warfare
Artificial Intelligence and Electronic WarfareArtificial Intelligence and Electronic Warfare
Artificial Intelligence and Electronic Warfare
 
Leveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and StandardsLeveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and Standards
 
Choosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptxChoosing The Best AWS Service For Your Website + API.pptx
Choosing The Best AWS Service For Your Website + API.pptx
 
Essentials of Automations: Exploring Attributes & Automation Parameters
Essentials of Automations: Exploring Attributes & Automation ParametersEssentials of Automations: Exploring Attributes & Automation Parameters
Essentials of Automations: Exploring Attributes & Automation Parameters
 
Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
 
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUHCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
 
What is an RPA CoE? Session 1 – CoE Vision
What is an RPA CoE?  Session 1 – CoE VisionWhat is an RPA CoE?  Session 1 – CoE Vision
What is an RPA CoE? Session 1 – CoE Vision
 
Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup SlidesProgramming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
 
The Microsoft 365 Migration Tutorial For Beginner.pptx
The Microsoft 365 Migration Tutorial For Beginner.pptxThe Microsoft 365 Migration Tutorial For Beginner.pptx
The Microsoft 365 Migration Tutorial For Beginner.pptx
 
Fueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte WebinarFueling AI with Great Data with Airbyte Webinar
Fueling AI with Great Data with Airbyte Webinar
 

REST & RESTful Web Services

  • 1. REST & RESTful WEB SERVICES
  • 2. In a Nutshell  REST is about resources and how to represent resources in different ways.  REST is about client-server communication.  REST is about how to manipulate resources.  REST offers a simple, interoperable and flexible way of writing web services that can be very different from other techniques.  Comes from Roy Fielding’s Thesis study.
  • 3. REST is NOT!  A protocol.  A standard.  A replacement for SOAP.
  • 4. REST  Representational State Transfer  Architectural style (technically not a standard)  Idea: a network of web pages where the client progresses through an application by selecting links  When client traverses link, accesses new resource (i.e., transfers state)  Uses existing standards, e.g., HTTP  REST is an architecture all about the Client-Server communication.
  • 5. An Architectural Style  REST is the architecture of the Web as it works today and, so it is already used in the web!  It is an software architectural model which is used to describe distributed systems like WWW (World Wide Web).  It has been developed in parallel with HTTP protocol.
  • 7. REST  Client requests a specific resource from the server.  The server responds to that request by delivering the requested resource.  Server does not have any information about any client.  So, there is no difference between the two requests of the same client.  A model which the representations of the resources are transferred between the client and the server.  The Web as we know is already in this form!
  • 8. Resources  Resources are just consistent mappings from an identifier [such as a URL path] to some set of views on server-side state.  Every resource must be uniquely addressable via a URI.  “If one view doesn’t suit your needs, then feel free to create a different resource that provides a better view. ”  “These views need not have anything to do with how the information is stored on the server … They just need to be understandable (and actionable) by the recipient.” Roy T. Fielding
  • 9. Requests & Responses  REQUEST GET /news/ HTTP/1.1 Host: example.org Accept-Encoding: compress, gzip User-Agent: Python-httplib2 Here is a GET request to «http://example.org/news/» Method = GET
  • 10. Requests & Responses  And here is the response…  RESPONSE HTTP/1.1 200 Ok Date: Thu, 07 Aug 2008 15:06:24 GMT Server: Apache ETag: "85a1b765e8c01dbf872651d7a5" Content-Type: text/html Cache-Control: max-age=3600 <!DOCTYPE HTML> ...
  • 11. Requests & Responses  The request is to a resource identified by a URI (URI = Unified Resource Identifier).  In this case, the resource is «http://example.org/news/»  Resources, or addressability is very important.  Every resource is URL-addressable.  To change system state, simply change a resource.
  • 12. URI Examples  http://localhost:9999/restapi/books  GET – get all books  POST – add a new book  http://localhost:9999/restapi/books/{id}  GET – get the book whose id is provided  POST – update the book whose id is provided  DELETE – delete the book whose id is provided
  • 13. REST Characteristics  Resources: Application state and functionality are abstracted into resources.  URI: Every resource is uniquely addressable using URIs.  Uniform Interface: All resources share a uniform interface for the transfer of state between client and resource, consisting of • Methods: Use only HTTP methods such as GET, PUT, POST, DELETE, HEAD • Representation  Protocol (The constraints and the principles)  Client-Server  Stateless  Cacheable  Layered
  • 14. HTTP Methods  GET – safe, idempotent, cacheable  PUT - idempotent  POST  DELETE - idempotent  HEAD  OPTIONS
  • 15. CRUD Operations Mapped to HTTP Methods in RESTful Web Services OPERATION HTTP METHOD Create POST Read GET Update PUT or POST Delete DELETE
  • 16.
  • 17. RESTful Web Services  RESTful web services are web services which are REST based.  Stateless & cacheable.  Uses URI & HTTP methods.  Frequently used with SOA projects.  Quiet light, extensible and simple services.  The reason behind the popularity of REST is that the applications we use are browser-based nowadays and top it all, REST is built on HTTP.  Main idea: Providing the communication between client and server over HTTP protocol rather than other complex architectures like SOAP and RPC etc.
  • 18. RESTful Web Services  You can do anything you already do with normal web services.  No severe restrictions on how the architectural model will be and what properties it will have.  Models like SOAP have severe rules, REST does not.  There are lots of frameworks to develop RESTful web services on platforms like C# and Java, but you can write one easily using some standard libraries.  Inspite of the low bandwidth, large data have been transfered with methods even inflating the size of the data, like XML with SOAP. Why?  Nowadays, the bandwidth is amazingly large, but we still use JSON and it shrinks the size of our data.
  • 19. RESTful Web Services  Platform independent.  Language independent.  Work on HTTP protocol.  Flexible and easily extendible.  They also have some constraints or principles.  Client-Server  Stateless  Cacheable  Uniform Interface  Layered System  Code on Demand
  • 20. Client-Server  Seperation of concerns.  Client and server are independent from eachother.  Client doesn’t know anything about the resource which is kept in the server.  Server responds as long as the right requests come in.  Goal: Platform independency and to improve scalability.
  • 21. Stateless  Each request is independent from other requests.  No client session data or any context stored on the server.  Every request from client stores the required information, so that the server can respond.  If there are needs for session-specific data, it should be held and maintained by the client and transferred to the server with each request as needed.  A service layer which doesn’t have to maintain client sessions is much easier to scale.  Of course there may be cumbersome situations:  The client must load the required information to every request. And this increases the network traffic.  Server might be loaded with heavy work of «validation» of requests. Scalability
  • 22. Cacheable  HTTP responses must be cacheable by the clients.  Important for performance.  If a new request for the resources comes within a while, then the cached response will be returned.
  • 23. Uniform Interface  All resources are accessed with a generic interface (HTTP-based).  This makes it easier to manage the communication.  By the help of a uniform interface, client and server evolve independently from eachother.  E.g. LEGO; eventhough there are different shaped pieces, there are only a few ways to pair up these pieces.
  • 24. Layered System  There can be many intermediaries between you and the server you are connecting to.  Actually, a client does not know if it is connected to the last server or an intermediary server.  Intermediaries may improve performance by caching and message passing.  Intermediary servers can increase scalability by load-balancing and can force clients to form some sort of security policies.  This structure can be used when encapsulation is needed.
  • 25. Code on Demand  Servers can send some kind of executable scripts to the client-side in order to increase or change the functionality on the client side.  This may cause low visibility, so it is the only optional constraint.  EXAMPLE ... <head> <script src="utility.js" type="text/javascript"> </script> ...
  • 26. more  If a service does not include all constraints out of «Code on Demand», it is not a RESTful web service.  The most epic constraint is «Stateless».
  • 27. What REST actually aims for?  Scalability  Simplicity  Modifiability  Useability  Portability  Reliability
  • 28. Benefits Network Performance  Efficiency  Scalability  User Perceived Performance Other Benefits  Simplicity  Evolvability  Reuseability  Visibility  Extensibility  Configuration  Customizability
  • 29. Benefits ctd.  HTTP is efficient because of all those caches, your request may not have to reach all the way back to the origin server.  Scalability comes from many areas. The use of layers allows you to distribute traffic among a large set of origin servers based on method, URI or content-type, or any other visible control data or meta-data in the request headers.  Caching also helps scalability as it reduces the actual number of requests that hit the origin server.  Statelessness allows requests to be routed through different gateways and proxies, thus avoiding introducing bottlenecks, allowing more intermediaries to be added as needed. [Scalability]
  • 30. Will REST Replace Other Technologies ?  There is actually an untold story that both technologies can be mixed and matched. REST is very easy to understand and is extremely approachable, but does lack standards and is considered an architectural approach. In comparison, SOAP is an industry standard with a well-defined protocol and a set of well-established rules to be implemented, and it has been used in systems both big and small.
  • 31. REST vs SOAP  SOAP is a XML-based message protocol, while REST is an architectural style.  SOAP uses WSDL for communication between consumer and provider, whereas REST just uses XML or JSON to send and receive data.  SOAP invokes services by calling RPC method, REST just simply calls services via URL path.  SOAP doesn't return human readable result, whilst REST result is readable with is just plain XML or JSON.  SOAP is not just over HTTP, it also uses other protocols such as SMTP, FTP, etc, REST is over only HTTP.
  • 32. SOAP uses WSDL for communication between consumer and provider, whereas REST just uses XML or JSON to send and receive data.  WSDL defines contract between client and service and is static by its nature. In case of REST contract is somewhat complicated and is defined by HTTP, URI, Media Formats and Application Specific Coordination Protocol. It's highly dynamic unlike WSDL.
  • 33. Performance is broad topic!-1  If you mean the load of the server, REST has a bit better performance because it bears minimal overhead on top of HTTP. Usually SOAP brings with it a stack of different (generated) handlers and parsers. Anyway, the performance difference itself is not that big, but RESTful service is more easy to scale up since you don't have any server side sessions.  If you mean the performance of the network (i.e. bandwidth), REST has much better performance. Basically, it's just HTTP. No overhead. So, if your service runs on top of HTTP anyway, you can't get much leaner than REST. Furthermore if you encode your representations in JSON (as opposed to XML), you'll save many more bytes.  In short, I would say 'yes', you'll be more performant with REST. Also, it (in my opinion) will make your interface easier to consume for your clients. So, not only your server becomes leaner but the client too.
  • 34. Performance is broad topic!-2 *However, couple of things to consider!  RESTful interfaces tend to be a bit more "chatty", so depending on your domain and how you design your resources, you may end up doing more HTTP requests.  SOAP has a very wide tool support. For example, consultants love it because they can use tools to define the interface and generate the WSDL file and developers love it because they can use another set of tools to generate all the networking code from that WSDL file. Moreover, XML as representation has schemas and validators, which in some cases may be a key issue. (JSON and REST do have similar stuff coming but the tool support is far behind)
  • 35. Complements or Competitors ?  There is some competition between proponents of each approach.  Yet both have value.  The challenge is to determine when to use each one !
  • 36. So the areas that REST works really well are:  Limited bandwidth and resources; remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.  Totally stateless operations; if an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.  Caching situations; if the information can be cached because of the totally stateless operation of the REST approach, this is perfect.
  • 37. So if you have the following then SOAP is a great solution:  Asynchronous processing and invocation; if your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.  Formal contracts; if both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.  Stateful operations; if the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.
  • 38. THANK YOU FOR YOUR PATIENCE AND LISTENING!