SlideShare a Scribd company logo
2
Most read
3
Most read
7
Most read
RE presentational  S tate  T ransfer
Think of REST this way –  when a browser gets and displays  the elements which make up an HTML page, it is getting a  representation  of the  current state of that  resource .
What is wrong with XML/RPC and SOAP  ? Roy Fielding feels that using HTTP to piggyback application protocols through firewalls the way XML-RPC and SOAP do is a fundamentally misguided idea.  It defeats the idea of having a firewall  and results in firewall vendors having to detect the piggybacked protocol in order to protect the system.  Since most SOAP applications use HTTP for exactly that purpose, you can see where the conflict between REST and SOAP got started. Fielding feels that if you are going to use HTTP, it should be with HTTP semantics.
Resources and Representations The last important bit is the distinction between a resource and its representations.  A resource is the real thing that is being acted upon with a request.  For example, deleting a file from a folder, adding an entry to a blog, or reading the heart rate of a patient.  The data transmitted to and from the resource is a representation of it.  Sometimes the representation can be faithful, such as in a file copy, and sometimes it's just a description, such as the sound of someone's voice. The end effect is that we never send or receive resources, only their representation.  The format of the representation is determined by the content-type.  And the interaction of the representation on the resource is determined by the verb.
REST Verbs Let’s explore the four basic verbs (GET, PUT, DELETE, POST) to define application behavior
GET The GET verb is  used to read a resource .  An important rule of thumb is that a GET operation is  safe .  That is, it can be done repeatedly without changing visibly the state of the resource.  This property is very important for various reasons.   First, indexing engines use GET to index the contents of a resource.  So it would be bad if indexing a resource also changed it.   Second,  intermediaries, such as proxies, may cache results of a GET operation to accelerate subsequent accesses to the same resource. Let's assume we have an image as a resource at "http://myserver/myphotos/mywedding.img".  We can retrieve this image by doing a GET operation on it: GET http://myserver/myphotos/mywedding.img  Similarly, we can also query a complex resource, such as a blog, to get parts of the data: GET http://myserver/myblog/2006-12-25T11:12:05.001Z/comments?query=author:anonymous  The GET verb is the fundamental read operation for resources.    All data resources support GET, but not all behavioral resources do. While a GET request cannot have side-effects, it can return only parts of the resource.  This means that  GET can act as both a read operation and a query operation .
PUT and DELETE The PUT and DELETE verbs  allow a request to alter the state of a resource atomically .   For example, if we wanted to change the image of our earlier example, we could upload a new one using the same URI and the PUT verb:  PUT http://myserver/myphotos/mywedding.img   This operation would indicate to the server that we want to replace the target resource with the contents of our request. Similarly, if we wanted to delete the image, we could use the DELETE verb: DELETE http://myserver/myphotos/mywedding.img   This operation states we want the server to delete or reset the target resource.   Note that PUT and DELETE apply to the entire resource and not just parts of it.  So, when doing a PUT operation, the entire resource is replaced .  PUT acts on the entire resource!  The same is true for DELETE: DELETE acts on the entire resource! The PUT and DELETE operations  are atomic .   If two PUT operations occur simultaneously, one of them will win and determine the final state of the resource.   The same is true when a PUT and DELETE operation occur simultaneously.  Either the resource's final state is updated or it is deleted, but nothing in between.  In the case of two simultaneous DELETE operations, the order does not matter, because deleting a resource again has no effect.
POST The POST verb can  carry a variety of meanings.   It's the Swiss Army Knife of HTTP verbs.  For some resources, it may be used to alter the internal state.  For others, it's behavior may be that of a remote procedure call ( http://en.wikipedia.org/wiki/Remote_procedure_call ). In the example of our blog, we could add a new blog by using the POST verb: POST http://myserver/myblog  The POST operation is very generic and no specific meaning can be attached to it.  In general, use POST when only a subset of a resource needs to be modified and it cannot be accessed as its own resource; or when the equivalent of a method call must be exposed.
First of all a web service  needs a communication channel . You need to be able to ask something to the service and the web service then needs to respond. In the REST web service you ask something just by typing a url.  In the url you give certain parameters that define which information you want the web service to return to you (just like giving GET variables to a page). If you made the correct web service call, it will respond you with an XML page containing the information you’ve asked. An example: http://www.somecompany.com/webservice/?searchuser=yoursearchstring if the user of the string exists the xml will be something like this: yoursearchstring The web service responds and says, I’ve found a user with that username. You can check the stat=”ok” parameter.  If the web service didn’t found a user with your search string it will respond something like this: stat=”fail”, with the error message “User not found”.  Your only task, as a programmer, is to catch that xml and parse it to usable data. And that’s all there is to it. Yes, it’s as simple as that.  Source --> http://www.bornontheweb.be/2006/03/01/rest-web-service-a-flickr-tutorial/

More Related Content

PPTX
Design Beautiful REST + JSON APIs
PDF
What is REST API? REST API Concepts and Examples | Edureka
PPTX
PPTX
REST & RESTful Web Services
PPTX
REST API
PDF
REST API and CRUD
PPTX
PPTX
REST API Design & Development
Design Beautiful REST + JSON APIs
What is REST API? REST API Concepts and Examples | Edureka
REST & RESTful Web Services
REST API
REST API and CRUD
REST API Design & Development

What's hot (20)

PPTX
PPTX
An Introduction To REST API
PPTX
Introduction to REST - API
PPTX
introduction about REST API
PDF
Rest web services
PPT
Introduction to the Web API
PPTX
Spring Boot and REST API
PDF
API Design, A Quick Guide to REST, SOAP, gRPC, and GraphQL, By Vahid Rahimian
PDF
Restful Web Services
PPTX
RESTful API - Best Practices
PDF
RESTful Web Services
PDF
Api presentation
PPTX
REST-API introduction for developers
PPTX
Understanding REST APIs in 5 Simple Steps
PPTX
API Design- Best Practices
PDF
OpenAPI 3.0, And What It Means for the Future of Swagger
PPTX
Rest presentation
PDF
API for Beginners
PDF
Spring Web Services: SOAP vs. REST
PPT
Graphql presentation
An Introduction To REST API
Introduction to REST - API
introduction about REST API
Rest web services
Introduction to the Web API
Spring Boot and REST API
API Design, A Quick Guide to REST, SOAP, gRPC, and GraphQL, By Vahid Rahimian
Restful Web Services
RESTful API - Best Practices
RESTful Web Services
Api presentation
REST-API introduction for developers
Understanding REST APIs in 5 Simple Steps
API Design- Best Practices
OpenAPI 3.0, And What It Means for the Future of Swagger
Rest presentation
API for Beginners
Spring Web Services: SOAP vs. REST
Graphql presentation
Ad

Similar to Understanding REST (20)

PPTX
Introduction To REST
PPTX
REST library.pptx
PDF
ReSTful API Final
PDF
[2015/2016] The REST architectural style
PPT
Web Tech Java Servlet Update1
PDF
Restful web-services
PPT
An Introduction To Java Web Technology
PDF
Introduction to Rest Protocol
PPT
Restful web services
PPTX
JAX-RS. Developing RESTful APIs with Java
PPT
The Rest Architectural Style
PPT
Salesforce REST API
PPTX
Ellerslie User Group - ReST Presentation
PDF
What are restful web services?
PPT
ROA.ppt
PPT
RESTful Services
PPTX
Lecture 12
PPTX
Best Practices in Api Design
PPTX
SFDC REST API
PDF
Resource-Oriented Web Services
Introduction To REST
REST library.pptx
ReSTful API Final
[2015/2016] The REST architectural style
Web Tech Java Servlet Update1
Restful web-services
An Introduction To Java Web Technology
Introduction to Rest Protocol
Restful web services
JAX-RS. Developing RESTful APIs with Java
The Rest Architectural Style
Salesforce REST API
Ellerslie User Group - ReST Presentation
What are restful web services?
ROA.ppt
RESTful Services
Lecture 12
Best Practices in Api Design
SFDC REST API
Resource-Oriented Web Services
Ad

Recently uploaded (20)

PDF
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
PDF
Spectral efficient network and resource selection model in 5G networks
PDF
Electronic commerce courselecture one. Pdf
PDF
Machine learning based COVID-19 study performance prediction
PDF
Per capita expenditure prediction using model stacking based on satellite ima...
PPTX
Programs and apps: productivity, graphics, security and other tools
PPTX
Spectroscopy.pptx food analysis technology
PPT
Teaching material agriculture food technology
PPTX
20250228 LYD VKU AI Blended-Learning.pptx
PDF
Optimiser vos workloads AI/ML sur Amazon EC2 et AWS Graviton
PDF
Diabetes mellitus diagnosis method based random forest with bat algorithm
PDF
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
PDF
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
PDF
NewMind AI Weekly Chronicles - August'25-Week II
PDF
Encapsulation theory and applications.pdf
PPTX
SOPHOS-XG Firewall Administrator PPT.pptx
PDF
Building Integrated photovoltaic BIPV_UPV.pdf
PDF
Empathic Computing: Creating Shared Understanding
PDF
Encapsulation_ Review paper, used for researhc scholars
PPTX
Machine Learning_overview_presentation.pptx
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
Spectral efficient network and resource selection model in 5G networks
Electronic commerce courselecture one. Pdf
Machine learning based COVID-19 study performance prediction
Per capita expenditure prediction using model stacking based on satellite ima...
Programs and apps: productivity, graphics, security and other tools
Spectroscopy.pptx food analysis technology
Teaching material agriculture food technology
20250228 LYD VKU AI Blended-Learning.pptx
Optimiser vos workloads AI/ML sur Amazon EC2 et AWS Graviton
Diabetes mellitus diagnosis method based random forest with bat algorithm
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
NewMind AI Weekly Chronicles - August'25-Week II
Encapsulation theory and applications.pdf
SOPHOS-XG Firewall Administrator PPT.pptx
Building Integrated photovoltaic BIPV_UPV.pdf
Empathic Computing: Creating Shared Understanding
Encapsulation_ Review paper, used for researhc scholars
Machine Learning_overview_presentation.pptx

Understanding REST

  • 1. RE presentational S tate T ransfer
  • 2. Think of REST this way – when a browser gets and displays the elements which make up an HTML page, it is getting a representation of the current state of that resource .
  • 3. What is wrong with XML/RPC and SOAP ? Roy Fielding feels that using HTTP to piggyback application protocols through firewalls the way XML-RPC and SOAP do is a fundamentally misguided idea. It defeats the idea of having a firewall and results in firewall vendors having to detect the piggybacked protocol in order to protect the system. Since most SOAP applications use HTTP for exactly that purpose, you can see where the conflict between REST and SOAP got started. Fielding feels that if you are going to use HTTP, it should be with HTTP semantics.
  • 4. Resources and Representations The last important bit is the distinction between a resource and its representations.  A resource is the real thing that is being acted upon with a request.  For example, deleting a file from a folder, adding an entry to a blog, or reading the heart rate of a patient.  The data transmitted to and from the resource is a representation of it.  Sometimes the representation can be faithful, such as in a file copy, and sometimes it's just a description, such as the sound of someone's voice. The end effect is that we never send or receive resources, only their representation.  The format of the representation is determined by the content-type.  And the interaction of the representation on the resource is determined by the verb.
  • 5. REST Verbs Let’s explore the four basic verbs (GET, PUT, DELETE, POST) to define application behavior
  • 6. GET The GET verb is used to read a resource .  An important rule of thumb is that a GET operation is safe .  That is, it can be done repeatedly without changing visibly the state of the resource.  This property is very important for various reasons.  First, indexing engines use GET to index the contents of a resource.  So it would be bad if indexing a resource also changed it.  Second, intermediaries, such as proxies, may cache results of a GET operation to accelerate subsequent accesses to the same resource. Let's assume we have an image as a resource at "http://myserver/myphotos/mywedding.img".  We can retrieve this image by doing a GET operation on it: GET http://myserver/myphotos/mywedding.img Similarly, we can also query a complex resource, such as a blog, to get parts of the data: GET http://myserver/myblog/2006-12-25T11:12:05.001Z/comments?query=author:anonymous The GET verb is the fundamental read operation for resources.   All data resources support GET, but not all behavioral resources do. While a GET request cannot have side-effects, it can return only parts of the resource.  This means that GET can act as both a read operation and a query operation .
  • 7. PUT and DELETE The PUT and DELETE verbs allow a request to alter the state of a resource atomically .  For example, if we wanted to change the image of our earlier example, we could upload a new one using the same URI and the PUT verb: PUT http://myserver/myphotos/mywedding.img This operation would indicate to the server that we want to replace the target resource with the contents of our request. Similarly, if we wanted to delete the image, we could use the DELETE verb: DELETE http://myserver/myphotos/mywedding.img This operation states we want the server to delete or reset the target resource. Note that PUT and DELETE apply to the entire resource and not just parts of it.  So, when doing a PUT operation, the entire resource is replaced .  PUT acts on the entire resource!  The same is true for DELETE: DELETE acts on the entire resource! The PUT and DELETE operations are atomic .  If two PUT operations occur simultaneously, one of them will win and determine the final state of the resource.  The same is true when a PUT and DELETE operation occur simultaneously.  Either the resource's final state is updated or it is deleted, but nothing in between.  In the case of two simultaneous DELETE operations, the order does not matter, because deleting a resource again has no effect.
  • 8. POST The POST verb can carry a variety of meanings.   It's the Swiss Army Knife of HTTP verbs.  For some resources, it may be used to alter the internal state.  For others, it's behavior may be that of a remote procedure call ( http://en.wikipedia.org/wiki/Remote_procedure_call ). In the example of our blog, we could add a new blog by using the POST verb: POST http://myserver/myblog The POST operation is very generic and no specific meaning can be attached to it.  In general, use POST when only a subset of a resource needs to be modified and it cannot be accessed as its own resource; or when the equivalent of a method call must be exposed.
  • 9. First of all a web service needs a communication channel . You need to be able to ask something to the service and the web service then needs to respond. In the REST web service you ask something just by typing a url. In the url you give certain parameters that define which information you want the web service to return to you (just like giving GET variables to a page). If you made the correct web service call, it will respond you with an XML page containing the information you’ve asked. An example: http://www.somecompany.com/webservice/?searchuser=yoursearchstring if the user of the string exists the xml will be something like this: yoursearchstring The web service responds and says, I’ve found a user with that username. You can check the stat=”ok” parameter. If the web service didn’t found a user with your search string it will respond something like this: stat=”fail”, with the error message “User not found”. Your only task, as a programmer, is to catch that xml and parse it to usable data. And that’s all there is to it. Yes, it’s as simple as that. Source --> http://www.bornontheweb.be/2006/03/01/rest-web-service-a-flickr-tutorial/