Integrating Restfully
       Srihari Srinivasan

       ThoughtWorks
Web 2.0

Platform for software development
1   :   3
Primer on REST



 • REST - Representational State Transfer
 • Term coined by Roy Fielding in his Ph.d thesis
Principled Architecture / Design

               of


Large Scale Distributed Systems
Primer on REST



•   Architectural style followed by the Web

•   Its Generic, can be used to build other web-like systems
Qualities


 •   Performance, Scalability, Interoperability

 •   Simplicity, Extensibility

 •   Visibility of Interactio...
REST intentionally places
Constraints on the system to achieve Desired Properties
REST - What it is not


 •   Not a standard, an architectural style

 •   Standards based on this style - HTTP, ATOM

 •  ...
REST - What it is not

•   Not the ONLY style for governing network interactions.

    •   Event Driven Architectures

   ...
REST Constraints
REST Constraints
•   Client-Server

•   Statelessness

•   Caching

•   Layered System

•   Uniform Interface

•   Code on...
Client-Server Style of Interactions


•   Based on the principle of separation of concerns

•   Client and Server can be d...
Uniform Interface


•   The central/distinguishing feature of REST

•   Most Controversial !
Uniform Interfaces are opposed to Specialized Interfaces
Specialized Interfaces
Employee Service
                          createEmployee(....)

                          updateEm...
What happens when lots of such special interfaces
          float in a distributed system ?
Specialization Consequences
 •   Clients have to know

     •   Method names, parameters

     •   Semantics of the method...
Specialization Consequences


 •   RPC style tries to map local computing notions to distribute operations

 •   Leads to ...
How does the Uniform Interface constraint help ?
Consequences of Specializing

 •   RPC/Service style interfaces promote specialization along two
     dimensions

      • ...
More Constraints
REST discourages sending ad hoc messages,
    invoking special purpose functions
Resources

•   Key Abstraction, Basic Unit of information

•   Can be anything interesting

    •   spreadsheet, image, xm...
Resources

•   Manipulated using representations - quot;Pass-by-valuequot; semantics

•   All resources manipulated via a ...
Resources

•   Representations can be in any format

•   Self describing messages help specify preferred formats

•   Clie...
How can a limited number of interfaces suffice
              to perform many
       domain specific operations ?
Resources
•   REST promotes replacing the quot;do somethingquot; concept with a quot;make
    something soquot; concept

•...
Hypermedia as the engine of application state
Hypermedia

•   Representations must contain next steps/transitions a resource can
    make from the current state

•   Us...
Resource Orientation
 •   HTTP GET from http://server.com/employees/name

 •   HTTP POST to http://server.coms/employees

...
Resource Orientation
•   Model Resources, instead of services

•   Assign identifiers to resources

•   Expose uniform oper...
Summary

•   REST tries to reveal the distribution in distributed systems

•   Popularizes HTTP outside the browser

•   R...
</presentation>
Integrating RESTfully
Integrating RESTfully
Integrating RESTfully
Upcoming SlideShare
Loading in …5
×

Integrating RESTfully

1,562 views

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,562
On SlideShare
0
From Embeds
0
Number of Embeds
46
Actions
Shares
0
Downloads
15
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Integrating RESTfully

  1. 1. Integrating Restfully Srihari Srinivasan ThoughtWorks
  2. 2. Web 2.0 Platform for software development
  3. 3. 1 : 3
  4. 4. Primer on REST • REST - Representational State Transfer • Term coined by Roy Fielding in his Ph.d thesis
  5. 5. Principled Architecture / Design of Large Scale Distributed Systems
  6. 6. Primer on REST • Architectural style followed by the Web • Its Generic, can be used to build other web-like systems
  7. 7. Qualities • Performance, Scalability, Interoperability • Simplicity, Extensibility • Visibility of Interactions • Reliability
  8. 8. REST intentionally places Constraints on the system to achieve Desired Properties
  9. 9. REST - What it is not • Not a standard, an architectural style • Standards based on this style - HTTP, ATOM • Ignores implementation details of components and protocol syntax
  10. 10. REST - What it is not • Not the ONLY style for governing network interactions. • Event Driven Architectures • Message Oriented Architecture • and good old RPC... • Most large systems have hybrid styles, one style may dominate though!
  11. 11. REST Constraints
  12. 12. REST Constraints • Client-Server • Statelessness • Caching • Layered System • Uniform Interface • Code on Demand (optional)
  13. 13. Client-Server Style of Interactions • Based on the principle of separation of concerns • Client and Server can be developed, maintained and scaled independently • Desired Properties : Simplicity, Scalability, Portability of user interfaces
  14. 14. Uniform Interface • The central/distinguishing feature of REST • Most Controversial !
  15. 15. Uniform Interfaces are opposed to Specialized Interfaces
  16. 16. Specialized Interfaces Employee Service createEmployee(....) updateEmployee(....) getEmployeeDetails(identifier) transferEmployee(identifier, to, ...) deleteEmployee(identifier)
  17. 17. What happens when lots of such special interfaces float in a distributed system ?
  18. 18. Specialization Consequences • Clients have to know • Method names, parameters • Semantics of the methods • Possibly the order of method calls • Each service interface is a new custom application protocol • Clients cannot be generic
  19. 19. Specialization Consequences • RPC style tries to map local computing notions to distribute operations • Leads to data specialization • Therefore couples format of the data to the interface
  20. 20. How does the Uniform Interface constraint help ?
  21. 21. Consequences of Specializing • RPC/Service style interfaces promote specialization along two dimensions • Operations • Data
  22. 22. More Constraints
  23. 23. REST discourages sending ad hoc messages, invoking special purpose functions
  24. 24. Resources • Key Abstraction, Basic Unit of information • Can be anything interesting • spreadsheet, image, xml file, transaction etc • Uniquely identifiable via a URI
  25. 25. Resources • Manipulated using representations - quot;Pass-by-valuequot; semantics • All resources manipulated via a limited set of standard functions/ operations • In HTTP we have GET, POST, PUT & DELETE with well defined semantics for each
  26. 26. Resources • Representations can be in any format • Self describing messages help specify preferred formats • Clients can even negotiate on formats with servers
  27. 27. How can a limited number of interfaces suffice to perform many domain specific operations ?
  28. 28. Resources • REST promotes replacing the quot;do somethingquot; concept with a quot;make something soquot; concept • “What” and not “How” • Think Declarative, instead of Imperative
  29. 29. Hypermedia as the engine of application state
  30. 30. Hypermedia • Representations must contain next steps/transitions a resource can make from the current state • Use hyperlinks to define these transitions
  31. 31. Resource Orientation • HTTP GET from http://server.com/employees/name • HTTP POST to http://server.coms/employees • HTTP PUT to http://server.com/employees/name • HTTP POST to http://server.com/employees/name/transfer • HTTP DELETE to http://server.com/employees/name
  32. 32. Resource Orientation • Model Resources, instead of services • Assign identifiers to resources • Expose uniform operations on resources based on your chosen protocol/framework • Support multiple formats - “One size does not fit all” • Leverage hypermedia to traverse through finite states
  33. 33. Summary • REST tries to reveal the distribution in distributed systems • Popularizes HTTP outside the browser • Reminds us that HTTP is not a transport protocol • The ideas of REST have merit even if you are doing classic SOA • Not easy to grok, requires unlearning and relearning!
  34. 34. </presentation>

×