Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
REST Explained
                                Representational State Transfer




                                       ...
What REST is not !
REST is not a ..




framework
REST is not a ..




technology
REST is not a ..




a standards specification
REST is an architecture style
.. as documented and described by Roy Fielding ..
.. which specifies a set of architecture constraints.
Fielding on Architecture Style
●   An architecture style is a coordinated set of
    architectural constraints that restri...
Architecture Constraint 1




  Client - Server
Client Server




Separates user interface concerns from data
            storage concerns
Client Server




Improves portability of interface across multiple
                   platforms
Client Server




Improves scalability by simplifying server
             components
Client Server




Allows the components to evolve independently
Architecture Constraint 2




   Statelessness
                            No Client State
Statelessness


Each request from client to server must contain all
 of the information necessary to understand the
 reque...
Statelessness




Session state is therefore kept entirely on the
                     client
Statelessness




Improved visibility since a monitoring system does
    not have to look beyond a single request
Statelessness




Improved reliability due to easier recoverability
             from partial failures
Statelessness




Improved scalability due to not having to allocate
          resources for storing state
Statelessness




Server does not have to manage resource usage
                across requests
Statelessness




Tradeoff : Reduced Network Performance
Statelessness




Tradeoff : Reduced server control over application
                  consistency
Statelessness is one of the most difficult to deal
                with constraints
                 (but more on that lat...
Architecture Constraint 3




Specified Cacheability
Specified Cacheability




Data within a response to a request be implicitly
   or explicitly labeled as cacheable or non-...
Specified Cacheability




If a response is cacheable, then a client cache is
  given the right to reuse that response dat...
Specified Cacheability




Improves efficiency, scalability and user perceived
                   performance
Specified Cacheability




Tradeoff : Reduced Reliability
Architecture Constraint 4




Uniform Interface
Uniform Interface




Overall system architecture is simplified and the
      visibility of interactions is improved
Uniform Interface




Implementations are decoupled from the services
    they provide and encourage independent
         ...
Uniform Interface




            Tradeoff : Degrades efficiency

since Information is transferred in a standardised form ...
Uniform Interface



                 Four interface constraints
       (more later .. we shall be spending the maximum ti...
Architecture Constraint 5




 Layered System
Layered System




Places a bound on overall system complexity
Layered System




Promotes substrate independence
Layered System




Can be used to encapsulate legacy services or
  protect new services from legacy clients
Layered System




Intermediaries can be used to improve system
     scalability by enabling load balancing
Layered System




Tradeoff : Add overhead and latency and reduce
           user perceived performance
Layered System




   Placing shared caches at boundaries of
organisational domain can result in significant
benefits. Can...
Layered System




 Intermediaries can actively transform message
content since messages are self descriptive and
their se...
Architecture Constraint 5




 Code on demand
(is an optional constraint)
Code on demand




   Client functionality can be extended by
downloading and executing code in the form of
              ...
Lets get back to .. and explore in far more detail ..
Interface constraints of ReST
Resources
Resources




What are resources ?
Any information that can be named is a resource
A resource is a conceptual mapping to a set of
entities not the entity itself. Such a mapping can
                change o...
This presentation is a resource
As is this presentation's latest version (if I am
   regularly backing it up to different files)
All available presentations on ReST is also a
 resource. A resource can be a collection of
                  entities too.
Resource Identifiers
Every resource has a name that uniquely
         identifies it – the URI
Names don't change
 (at least not frequently)
Think of it like a primary key for each row in a
                      database

http://informationbase/locationdb/citiest...
REST doesn't dictate URI choice.
Leaves it to the application author.
The URI should generally carry no meaning to the
      client except as a resource locator
However don't let that encourage you to name
     URIs arbitrarily and confusingly
Good, clean, structured URIs are helpful for
                developers
If you are naming a specific single resource all the
information to locate the resource should be in the
  URI itself and ...
eg. choose
  http://informationbase/locationdb/citiestable/pune
                          not
http://informationbase/locat...
However optional parameters for identifying
 subsets of resources are conventionally
               acceptable
eg.
http://ibase/cities?startswith=pu&start=11&count=10
Resources have Representations
A representation captures the current or intended
               state of a resource
Resources are transferred between the client and
                  the server
Resources may include metadata describing
              themselves
A particular resource may have multiple
             representations
Commonly used representation formats are
          html, xml and json

 however they could also be pdf, png etc.
When multiple resource formats are supported by
the server, the actual resource format returned is
subject to content nego...
This should ideally happen through control data
i.e. By using HTTP “Accept” headers and not by
  appending additional info...
REST doesn't dictate or constrain you to using
particular representation formats. Use what suits
         the application ...
Interface constraint 3




Self descriptive messages
Requests and responses contain inband
 description about the schema it adopts
This is done by describing the XML Schema for
the representation (or its units) using the same by
declaring its appropriat...
The entire schema does not need to be known
upfront. Only the mandatory and relevant parts
               need to be known.
The schema can continue to be extended without
 client modifications if it is only adding optional
             elements o...
Intermediate layers can both parse and transform
              messages intelligently
Metadata helps both page and form rendering and
client side validations could be introduced based
    on an understanding ...
Interface constraint 4




Hypermedia as the engine of application state
               (HATEOAS)
Hypermedia


Hypermedia is used as a logical extension of the
 term hypertext in which graphics, audio, video,
  plain tex...
HyperText


 Simultaneous presentation of information and
controls such that the information becomes the
  affordance thro...
Application State

state that determines "where" the user is in the
          process of completing a task

It is not the ...
To understand application state, you need to
visualise the pages / resources of the application
  as a wireframe model or ...
Each state allows for only a few valid triggers to
     allow it to navigate to another state
These possible navigations out of the state can be
   embedded in the resource representation
  overlying the state by usi...
Since each state self describes the possible links
given the context, the client can choose to select
    the appropriate ...
To put it differently

 Make hypermedia constrain client choices, and
the client choice influences the application state
Therefore :
Hypermedia as the engine of application state
Client needs to know only the starting URL
In addition client needs to be able to understand
 the mediatypes and semantics associated with
  the links (ie. What does...
One more aspect of Uniform Interfaces
Uniform Operations
In case of database tables, these are
    Insert, Select, Update, Delete
In common parlance these are
Create, Read, Update, Delete (CRUD)
In REST over HTTP these are
  POST, GET, PUT, DELETE
Those are the only verbs you need
Simplifies semantics
Simplifies client complexity
Simplifies application model
Clients interact with REST based systems by
sequentially performing one of POST, GET, PUT,
DELETE operations on self descr...
For this clients need to understand resource
representation schemas (xml schemas) and ...
Client need to understand semantics of the
relationship types (<link rel=”...”>) offered by the
                      serv...
REST is the DBMS of the internet
With a slight caveat
It doesn't break encapsulation
It exposes resource representations and not
           resources themselves
Thats like a parallel set of tables / views that
clients can access and which have triggers which
    in turn appropriatel...
Its often much easier and quicker to understand
  table schemas than it is to understand stored
             procedure sem...
This is an important distinction compared to RPC/
 SOA based architectures which in case of this
   analogy would represen...
Which is why a client is likely to be far quicker off
 the starting block if given a set of schemas and
standard SQL seman...
Sample ReST request
Sample ReST response
ReST simplifies
●   Hypertext is standardised. Fewer UIs
●   Identification is standardised. Lesser
    communication
●   Exchange protoco...
No IDLs, WADLs, WSDLs
No static compilations required
No methods and what each method means
No inter method sequencing
No registries
When dealing with complex stuff,
       you always feel,
   you can use some rest.
When you use ReST, things are simpler
Benefits of REST




               - Roy Fielding
Uniform resources having identifiers increases
               reuse potential
Uniform interface hides implementation details
           supporting low coupling
Hypertext allows for late binding leading to
reduction in attempted inappropriate accesses
              and resultant err...
Server failures don't befuddle client state leading,
while shared state is easily recoverable leading to
             impr...
Supports gradual and fragmented change across
                organisations.
Services can be layered, clustered and cached
        leading to improved scalability
ReST extends the very capabilities that made
WWW successful into application design and
               architecture
What are these characteristics of static W W W
                 and ReST?
You can connect to any web server if you know
            the home page URL




You can connect to ReST application if you...
On the home page you can view the content
   along with the appropriate hyperlinks which
  suggest appropriate paths for y...
You can navigate to the next page by clicking on
                 the hyperlink




 You can conduct an operation by perfo...
You can save the hyperlink URL, bookmark it or
  email it to you boss or tweet it to your friends



 A ReST client can st...
They will not need to repeat your sequence of
 steps. They will be able to directly access the
              page given th...
You can save the contents of any page by saving
           its HTML representation




You can save the representation of ...
You can modify the contents of the web pages by
entering data in forms (and even full page content
     in blogs, Wikis et...
You can upload new files by browsing for the file
 on your desktop and submitting the button on
   appropriately configure...
The server retains no information about the pages
                 you've traversed




The server retains no information ...
The server can send you different media types
(eg. HTML, PDF, Videos etc.) by describing these
           media types in t...
Did you notice there is no global internet registry
             for website discovery ?


     There is no registry requi...
Yahoo tried, as does Open Directory but it just
                 doesn't work



 And it may not for many other architectu...
Since the content depends on basic HTML tags
and each URL is uniquely addressable, it is easy
for search engines to index ...
These are all characteristics that made static www
  simple to use, deploy and leverage making it
      popular and eventu...
Designing ReSTful applications
Using a ReST supportive framework does not
       make your application ReSTful
You need to model your application interfaces as
              a set of resources
And basic CRUD operations on these resources
Since controllers in traditional web frameworks
  drive the interface, we shall focus on these
When the interface is meant for browsers, there
 are some limitations. Hence browser oriented
interfaces are a little diff...
Assuming each controller represents a lifecycle
manager for a particular resource type, it needs a
 few basic methods. And...
Resource URI        HTTP     Controller   Description
                    Method   Method
/cities             GET      ind...
No more actions like
    city.expand (CityExpansion.create) ,
city.holdElections (CityElection.create) etc.
You will need to create new controllers which
represent new nouns representing the action
Not all controllers will implement all methods. But
 they should not implement any more methods.
As you move from an action oriented design
  towards resource oriented design, thinking of
everything as nouns is one of t...
Transaction.approve becomes TransactionApproval

  Account.pay become AccountPayment.create

                   etc. etc.
For each resource you need to document the
    XML Schema and define a mime type
            (application/vnd.***)

especi...
For each resource representation you need to list
 what are the appropriate URIs (application state
     transitions) to b...
REST and Security
This is one area where I choose to be non
                 ReSTful
Sometimes the deliberate requirements of
opaqueness of security and transparency of ReST
             don't cooperate well
Cookies

Cookie interaction fails to match REST's model of
 application state, often resulting in confusion for
          ...
I agree with that .. but ...
Cookies can help in user identification (other
 options being Basic HTTP authentication)
Basic HTTP Authentication is weak
Computes a hash which can be intercepted and
               reused later
If you do use Basic HTTP authentication at the
             minimum use HTTPS
But I prefer cookies when they are strictly used for
               user identification only
But cookies break the statelessness model
Yes they do. I prefer to store only the data thats
 expensive to compute but can be recomputed in
case of loss in the sess...
That is hard to ensure .. and thats another self
        imposed architecture constraint
But I think it is more practical for secure
                 applications
Even though it takes away their ability of being
           called 100% ReSTful
What about alternative architecture styles (SOA) ?
They are an extension of the RPC construct not
              the www construct
They simply do not have most of the benefits I just
                   referred to
And the hype-engine is really struggling to
compete with the wide successes of ReST
Experience has shown when sites offered both
SOA and ReST interfaces, clients quickly ended
             up choosing ReST
...
Rest is not SOA
They both attempt to solve a similar set of
              problems ....
.... differently!
●   ReST requires you to think resources not
    actions or services
●   ReST requires you to lay a greater emphasis on
  ...
The clear distinctions between ROA and SOA are
  being blurred for non technical reasons. Be
     aware when you read cont...
SOA is the evolution of RPC semantics

ReST / ROA is the evolution of www semantics
A look forward to increasing ReST popularity
ReST already is starting to dominate the internet
  space and there's a good likelihood it could
   dominate enterprise ar...
References and Sources


●   Roy Fielding's Dissertation on ReST
●   A little REST and Relaxation : presentation by Roy Fi...
Thank You !
Upcoming SlideShare
Loading in …5
×

ReST (Representational State Transfer) Explained

32,595 views

Published on

A long presentation on a variety of aspects of REST.

  • Nice !! Download 100 % Free Ebooks, PPts, Study Notes, Novels, etc @ https://www.ThesisScientist.com 1 week ago
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Excellent presentation on REST
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Njce! Thanks for sharing.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • This is real take it serious, who will believe that a herb can cure herpes, i navel believe that this will work i have spend a lot when getting drugs from the hospital to keep me healthy, what i was waiting for is death because i was broke, one day i hard about this great man who is well know of HIV and cancer cure, i decided to email him, unknowingly to me that this will be the end of the herpes in my body, he prepare the herb for me, and give me instruction on how to take it, at the end of the one month, he told me to go to the hospital for a check up, and i went, surprisingly after the test the doctor confirm me negative, i thought it was a joke, i went to other hospital was also negative, then i took my friend who was also herpes positive to the Dr Agumagu, after the treatment she was also confirm negative . He also have the herb to cure cancer. please i want every one with this virus to be free, that is why am dropping his email address, agumaguspelltemple@outlook.com or agumaguspelltemple@gmail.com do email him he is a great man. the government is also interested in this DR, thank you for saving my life, and I promise I will always testify for your good work.call his number +233200116937
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • how can i have a copy?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

ReST (Representational State Transfer) Explained

  1. 1. REST Explained Representational State Transfer Dhananjay Nene July 4, 2009 TechWeekend – Pune http://blog.dhananjaynene.com http://twitter.com/dnene
  2. 2. What REST is not !
  3. 3. REST is not a .. framework
  4. 4. REST is not a .. technology
  5. 5. REST is not a .. a standards specification
  6. 6. REST is an architecture style
  7. 7. .. as documented and described by Roy Fielding ..
  8. 8. .. which specifies a set of architecture constraints.
  9. 9. Fielding on Architecture Style ● An architecture style is a coordinated set of architectural constraints that restricts the roles and features of architectural elements, and the allowed relationships between those elements, within any architecture that conforms to that style ● A style can be applied to many architectures ● An architecture can consist of many styles
  10. 10. Architecture Constraint 1 Client - Server
  11. 11. Client Server Separates user interface concerns from data storage concerns
  12. 12. Client Server Improves portability of interface across multiple platforms
  13. 13. Client Server Improves scalability by simplifying server components
  14. 14. Client Server Allows the components to evolve independently
  15. 15. Architecture Constraint 2 Statelessness No Client State
  16. 16. Statelessness Each request from client to server must contain all of the information necessary to understand the request and cannot take any advantage of any stored context on the server. and Each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have preceded it
  17. 17. Statelessness Session state is therefore kept entirely on the client
  18. 18. Statelessness Improved visibility since a monitoring system does not have to look beyond a single request
  19. 19. Statelessness Improved reliability due to easier recoverability from partial failures
  20. 20. Statelessness Improved scalability due to not having to allocate resources for storing state
  21. 21. Statelessness Server does not have to manage resource usage across requests
  22. 22. Statelessness Tradeoff : Reduced Network Performance
  23. 23. Statelessness Tradeoff : Reduced server control over application consistency
  24. 24. Statelessness is one of the most difficult to deal with constraints (but more on that later)
  25. 25. Architecture Constraint 3 Specified Cacheability
  26. 26. Specified Cacheability Data within a response to a request be implicitly or explicitly labeled as cacheable or non- cacheable
  27. 27. Specified Cacheability If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests
  28. 28. Specified Cacheability Improves efficiency, scalability and user perceived performance
  29. 29. Specified Cacheability Tradeoff : Reduced Reliability
  30. 30. Architecture Constraint 4 Uniform Interface
  31. 31. Uniform Interface Overall system architecture is simplified and the visibility of interactions is improved
  32. 32. Uniform Interface Implementations are decoupled from the services they provide and encourage independent evolvability
  33. 33. Uniform Interface Tradeoff : Degrades efficiency since Information is transferred in a standardised form rather than one which is specific to application's needs
  34. 34. Uniform Interface Four interface constraints (more later .. we shall be spending the maximum time on this) ● Identification of resources ● Manipulation of resources through representations ● Self descriptive messages ● Hypermedia as the engine of application state (HATEOAS)
  35. 35. Architecture Constraint 5 Layered System
  36. 36. Layered System Places a bound on overall system complexity
  37. 37. Layered System Promotes substrate independence
  38. 38. Layered System Can be used to encapsulate legacy services or protect new services from legacy clients
  39. 39. Layered System Intermediaries can be used to improve system scalability by enabling load balancing
  40. 40. Layered System Tradeoff : Add overhead and latency and reduce user perceived performance
  41. 41. Layered System Placing shared caches at boundaries of organisational domain can result in significant benefits. Can also enforce security policies eg. firewalls
  42. 42. Layered System Intermediaries can actively transform message content since messages are self descriptive and their semantics are visible to the intermediaries
  43. 43. Architecture Constraint 5 Code on demand (is an optional constraint)
  44. 44. Code on demand Client functionality can be extended by downloading and executing code in the form of applets or scripts
  45. 45. Lets get back to .. and explore in far more detail ..
  46. 46. Interface constraints of ReST
  47. 47. Resources
  48. 48. Resources What are resources ?
  49. 49. Any information that can be named is a resource
  50. 50. A resource is a conceptual mapping to a set of entities not the entity itself. Such a mapping can change over time.
  51. 51. This presentation is a resource
  52. 52. As is this presentation's latest version (if I am regularly backing it up to different files)
  53. 53. All available presentations on ReST is also a resource. A resource can be a collection of entities too.
  54. 54. Resource Identifiers
  55. 55. Every resource has a name that uniquely identifies it – the URI
  56. 56. Names don't change (at least not frequently)
  57. 57. Think of it like a primary key for each row in a database http://informationbase/locationdb/citiestable/pune
  58. 58. REST doesn't dictate URI choice. Leaves it to the application author.
  59. 59. The URI should generally carry no meaning to the client except as a resource locator
  60. 60. However don't let that encourage you to name URIs arbitrarily and confusingly
  61. 61. Good, clean, structured URIs are helpful for developers
  62. 62. If you are naming a specific single resource all the information to locate the resource should be in the URI itself and not through additional parameters
  63. 63. eg. choose http://informationbase/locationdb/citiestable/pune not http://informationbase/locator?type=city&name=pune
  64. 64. However optional parameters for identifying subsets of resources are conventionally acceptable
  65. 65. eg. http://ibase/cities?startswith=pu&start=11&count=10
  66. 66. Resources have Representations
  67. 67. A representation captures the current or intended state of a resource
  68. 68. Resources are transferred between the client and the server
  69. 69. Resources may include metadata describing themselves
  70. 70. A particular resource may have multiple representations
  71. 71. Commonly used representation formats are html, xml and json however they could also be pdf, png etc.
  72. 72. When multiple resource formats are supported by the server, the actual resource format returned is subject to content negotiation between the client and the server
  73. 73. This should ideally happen through control data i.e. By using HTTP “Accept” headers and not by appending additional information to the URL. Prefer Accept: text/xml;q=0.5, application/json http://infobase/cities/pune to http://infobase/cities/pune.json
  74. 74. REST doesn't dictate or constrain you to using particular representation formats. Use what suits the application context the best.
  75. 75. Interface constraint 3 Self descriptive messages
  76. 76. Requests and responses contain inband description about the schema it adopts
  77. 77. This is done by describing the XML Schema for the representation (or its units) using the same by declaring its appropriate XML namespace. Further clarity can be introduced by using a custom “application/vnd.*****” Content-Type header.
  78. 78. The entire schema does not need to be known upfront. Only the mandatory and relevant parts need to be known.
  79. 79. The schema can continue to be extended without client modifications if it is only adding optional elements or attributes.
  80. 80. Intermediate layers can both parse and transform messages intelligently
  81. 81. Metadata helps both page and form rendering and client side validations could be introduced based on an understanding of the schema and its semantics
  82. 82. Interface constraint 4 Hypermedia as the engine of application state (HATEOAS)
  83. 83. Hypermedia Hypermedia is used as a logical extension of the term hypertext in which graphics, audio, video, plain text and hyperlinks intertwine to create a generally non-linear medium of information. source : Wikipedia
  84. 84. HyperText Simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions - Roy Fielding
  85. 85. Application State state that determines "where" the user is in the process of completing a task It is not the resource or state of the resource on the server
  86. 86. To understand application state, you need to visualise the pages / resources of the application as a wireframe model or a state machine and each page as a state
  87. 87. Each state allows for only a few valid triggers to allow it to navigate to another state
  88. 88. These possible navigations out of the state can be embedded in the resource representation overlying the state by using hypertext (links)
  89. 89. Since each state self describes the possible links given the context, the client can choose to select the appropriate link by examining the link metadata.
  90. 90. To put it differently Make hypermedia constrain client choices, and the client choice influences the application state
  91. 91. Therefore : Hypermedia as the engine of application state
  92. 92. Client needs to know only the starting URL
  93. 93. In addition client needs to be able to understand the mediatypes and semantics associated with the links (ie. What does a link with a particular “rel” type mean)
  94. 94. One more aspect of Uniform Interfaces
  95. 95. Uniform Operations
  96. 96. In case of database tables, these are Insert, Select, Update, Delete
  97. 97. In common parlance these are Create, Read, Update, Delete (CRUD)
  98. 98. In REST over HTTP these are POST, GET, PUT, DELETE
  99. 99. Those are the only verbs you need
  100. 100. Simplifies semantics
  101. 101. Simplifies client complexity
  102. 102. Simplifies application model
  103. 103. Clients interact with REST based systems by sequentially performing one of POST, GET, PUT, DELETE operations on self describing resources and by traversing the links offered by the server
  104. 104. For this clients need to understand resource representation schemas (xml schemas) and ...
  105. 105. Client need to understand semantics of the relationship types (<link rel=”...”>) offered by the server
  106. 106. REST is the DBMS of the internet
  107. 107. With a slight caveat
  108. 108. It doesn't break encapsulation
  109. 109. It exposes resource representations and not resources themselves
  110. 110. Thats like a parallel set of tables / views that clients can access and which have triggers which in turn appropriately update the real tables
  111. 111. Its often much easier and quicker to understand table schemas than it is to understand stored procedure semantics
  112. 112. This is an important distinction compared to RPC/ SOA based architectures which in case of this analogy would represent stored procedures
  113. 113. Which is why a client is likely to be far quicker off the starting block if given a set of schemas and standard SQL semantics to work with rather than a list of stored procedures describing each procedure, its parameters and the interrelationships between the procedures. Thats what makes ReST so much easier for its clients and users
  114. 114. Sample ReST request
  115. 115. Sample ReST response
  116. 116. ReST simplifies
  117. 117. ● Hypertext is standardised. Fewer UIs ● Identification is standardised. Lesser communication ● Exchange protocols are standardised. Fewer Integrations ● Interactions are standardised. Fewer semantics ● Data formats are standardised. Fewer translations - Roy Fielding
  118. 118. No IDLs, WADLs, WSDLs
  119. 119. No static compilations required
  120. 120. No methods and what each method means
  121. 121. No inter method sequencing
  122. 122. No registries
  123. 123. When dealing with complex stuff, you always feel, you can use some rest.
  124. 124. When you use ReST, things are simpler
  125. 125. Benefits of REST - Roy Fielding
  126. 126. Uniform resources having identifiers increases reuse potential
  127. 127. Uniform interface hides implementation details supporting low coupling
  128. 128. Hypertext allows for late binding leading to reduction in attempted inappropriate accesses and resultant errors
  129. 129. Server failures don't befuddle client state leading, while shared state is easily recoverable leading to improved fault tolerance
  130. 130. Supports gradual and fragmented change across organisations.
  131. 131. Services can be layered, clustered and cached leading to improved scalability
  132. 132. ReST extends the very capabilities that made WWW successful into application design and architecture
  133. 133. What are these characteristics of static W W W and ReST?
  134. 134. You can connect to any web server if you know the home page URL You can connect to ReST application if you know the starting URI
  135. 135. On the home page you can view the content along with the appropriate hyperlinks which suggest appropriate paths for you to traverse The response will provide you important initial content along with hyperlinks which describe their nature to navigate to other resources
  136. 136. You can navigate to the next page by clicking on the hyperlink You can conduct an operation by performing a POST/GET/PUT/DELETE on one of the suggested URIs
  137. 137. You can save the hyperlink URL, bookmark it or email it to you boss or tweet it to your friends A ReST client can store a URI for future use or embed it as a foreign key in other resources that it maintains
  138. 138. They will not need to repeat your sequence of steps. They will be able to directly access the page given the URL. The receiving ReST client will be able to directly access the earlier stored URI without going through a sequence of pages
  139. 139. You can save the contents of any page by saving its HTML representation You can save the representation of any resource into a XML / Document database
  140. 140. You can modify the contents of the web pages by entering data in forms (and even full page content in blogs, Wikis etc.) and POSTing them. You can perform PUT, POST and DELETE operations on resources to modify them
  141. 141. You can upload new files by browsing for the file on your desktop and submitting the button on appropriately configured pages (PUT file) You can add new resources by conducting the POST operation
  142. 142. The server retains no information about the pages you've traversed The server retains no information about you or the pages you've traversed
  143. 143. The server can send you different media types (eg. HTML, PDF, Videos etc.) by describing these media types in the headers The server sends the metadata describing the resource representation inband with the representation
  144. 144. Did you notice there is no global internet registry for website discovery ? There is no registry required for ReST applications
  145. 145. Yahoo tried, as does Open Directory but it just doesn't work And it may not for many other architectures requiring registries
  146. 146. Since the content depends on basic HTML tags and each URL is uniquely addressable, it is easy for search engines to index its content and allow users to find the required pages Representations for URIs can be browsed, indexed and eventually searched through
  147. 147. These are all characteristics that made static www simple to use, deploy and leverage making it popular and eventually omnipresent These are also characteristics of ReST contributing to its simplicity and ease of leveraging accounting for its popularity
  148. 148. Designing ReSTful applications
  149. 149. Using a ReST supportive framework does not make your application ReSTful
  150. 150. You need to model your application interfaces as a set of resources
  151. 151. And basic CRUD operations on these resources
  152. 152. Since controllers in traditional web frameworks drive the interface, we shall focus on these
  153. 153. When the interface is meant for browsers, there are some limitations. Hence browser oriented interfaces are a little different than POST, GET, PUT, DELETE
  154. 154. Assuming each controller represents a lifecycle manager for a particular resource type, it needs a few basic methods. And the same methods get reproduced across all such controllers
  155. 155. Resource URI HTTP Controller Description Method Method /cities GET index Get list of cities (optional params) /cities POST create Create a new city /cities/Pune GET show Show pune resource representation /cities/Pune PUT update Modify pune resource /cities/Pune DELETE destroy Delete pune resource /cities/new GET new Initiate a new city resource creation /cities/Pune;edit GET edit Initiate a new city modification
  156. 156. No more actions like city.expand (CityExpansion.create) , city.holdElections (CityElection.create) etc.
  157. 157. You will need to create new controllers which represent new nouns representing the action
  158. 158. Not all controllers will implement all methods. But they should not implement any more methods.
  159. 159. As you move from an action oriented design towards resource oriented design, thinking of everything as nouns is one of the early challenges to overcome
  160. 160. Transaction.approve becomes TransactionApproval Account.pay become AccountPayment.create etc. etc.
  161. 161. For each resource you need to document the XML Schema and define a mime type (application/vnd.***) especially when the consumer is a machine
  162. 162. For each resource representation you need to list what are the appropriate URIs (application state transitions) to be returned along with the representations and implement introduction of these in the controller actions as well
  163. 163. REST and Security
  164. 164. This is one area where I choose to be non ReSTful
  165. 165. Sometimes the deliberate requirements of opaqueness of security and transparency of ReST don't cooperate well
  166. 166. Cookies Cookie interaction fails to match REST's model of application state, often resulting in confusion for the typical browser application. - Roy Fielding
  167. 167. I agree with that .. but ...
  168. 168. Cookies can help in user identification (other options being Basic HTTP authentication)
  169. 169. Basic HTTP Authentication is weak
  170. 170. Computes a hash which can be intercepted and reused later
  171. 171. If you do use Basic HTTP authentication at the minimum use HTTPS
  172. 172. But I prefer cookies when they are strictly used for user identification only
  173. 173. But cookies break the statelessness model
  174. 174. Yes they do. I prefer to store only the data thats expensive to compute but can be recomputed in case of loss in the session against the cookie. No storage of conversational state in the session
  175. 175. That is hard to ensure .. and thats another self imposed architecture constraint
  176. 176. But I think it is more practical for secure applications
  177. 177. Even though it takes away their ability of being called 100% ReSTful
  178. 178. What about alternative architecture styles (SOA) ?
  179. 179. They are an extension of the RPC construct not the www construct
  180. 180. They simply do not have most of the benefits I just referred to
  181. 181. And the hype-engine is really struggling to compete with the wide successes of ReST
  182. 182. Experience has shown when sites offered both SOA and ReST interfaces, clients quickly ended up choosing ReST - sounds intituitive enough to me but do not recollect the source.
  183. 183. Rest is not SOA
  184. 184. They both attempt to solve a similar set of problems ....
  185. 185. .... differently!
  186. 186. ● ReST requires you to think resources not actions or services ● ReST requires you to lay a greater emphasis on documentation of your schema and practically none on the actions ● ReST requires you to provide in band metadata ● ReST works very nicely with layered architectures ● Another way to describe ReST is ROA : Resource Oriented Architecture
  187. 187. The clear distinctions between ROA and SOA are being blurred for non technical reasons. Be aware when you read content debating ReST/SOA (including this presentation)
  188. 188. SOA is the evolution of RPC semantics ReST / ROA is the evolution of www semantics
  189. 189. A look forward to increasing ReST popularity
  190. 190. ReST already is starting to dominate the internet space and there's a good likelihood it could dominate enterprise architectures as well.
  191. 191. References and Sources ● Roy Fielding's Dissertation on ReST ● A little REST and Relaxation : presentation by Roy Fielding ● Pragmatic Intro to REST and SOA, REST and the Web: presentations by Stephan Tilkov ● Pragmatic REST And RESTful Web Apps: presentations by Subbu Allamaraju ● Describing RESTful applications : Article by Subbu Allamaraju at InfoQ. ● RESTful Best Practices : presentation by calamitas ● The REST architectural style : presentation by Robert Wilson
  192. 192. Thank You !

×