Unerstanding and Using RESTful APIs

2,439 views

Published on

KeyLimeTie CTO Peter Morano provides an overview of using REST to architect applications. Complete with examples and resources.

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

No Downloads
Views
Total views
2,439
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
121
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • From My ExperienceKLT builds software based on multiple logical tiers, so it was important for us find a way to cleanly integrate REST calls into our existing patterns.We generate custom code generators do produce our DAL and BLL code, generating 1000’s of lines of optimized code in seconds based on any database schema.
  • Unerstanding and Using RESTful APIs

    1. 1. REST 11.07.2009<br />Understanding and Using RESTful APIs<br />
    2. 2. About Me<br /><ul><li>Developing software for 15 years
    3. 3. Bulk of experience on enterprise-scale applications
    4. 4. Microsoft platform (mostly)
    5. 5. CTO at KeyLimeTie</li></li></ul><li>Overview<br />Although REST is 10 years old, APIs based on the REST model continue to become an integral part of the technology landscape. <br />ProgrammableWeb.com lists 1051 RESTful APIs, 4422 Mashups.<br />We’ll look at<br /><ul><li>Basic REST Concepts
    6. 6. Using REST
    7. 7. WADL</li></li></ul><li>Rest overview<br />
    8. 8. REST Overview<br />APIs based on the Representational State Transfer (REST) architecture dominate web 2.0 mash-up and social media development.<br />There are a number of frameworks available that support the development of RESTful APIs (WCF, JAX-RS, Wicket, Zend)<br />We are still missing an established mechanism for documentation and discovery and client-side tool support for rapid implementation.<br />
    9. 9. REST Overview<br />REST-style architectures consist of clients and servers. <br />Requests and responses are built around the transfer of &quot;representations&quot; of &quot;resources&quot;. <br />A resource is any entity that can be addressed in a URI (an account, an employee, a physical file)<br />A representation of a resource is any information that captures the current or intended state of a resource. All information necessary to process and complete a request is contained within it.<br />
    10. 10. Example<br />Resource (Twitter Public Timeline) http://twitter.com/statuses/public_timeline.xml<br />Resource (Twitter User) <br />http://twitter.com/users/petermorano.xml<br />
    11. 11. REST Overview<br />REST-style architectures consist of clients and servers. <br />Requests and responses are built around the transfer of &quot;representations&quot; of &quot;resources&quot;. <br />A resource is any entity that can be addressed in a URI (an account, an employee, a physical file)<br />A representation of a resource is any information that captures the current or intended state of a resource. All information necessary to process and complete a request is contained within it.<br />
    12. 12. Wait a Minute<br />If this sounds a lot like the Web, it’s because the Web is a REST implementation<br />Roy Fielding, who created REST, was also one of the principal authors of HTTP<br />
    13. 13. REST Basics<br />The REST architecture was designed around a few key principles:<br /><ul><li> Use HTTP Methods (and Response Codes)
    14. 14. Be Stateless and Cacheable
    15. 15. Use Addressable Resources
    16. 16. Support the transfer of Representations</li></li></ul><li>REST Basics<br />The REST architecture was designed around a few key principles:<br /><ul><li>Use HTTP Methods (and Response Codes)
    17. 17. Be Stateless and Cacheable
    18. 18. Use Addressable Resources
    19. 19. Support the transfer of Representations</li></li></ul><li>HTTP Methods<br />Map to CRUD Operations<br />Action<br />SQL<br />HTTP Method<br />Create<br />Insert<br />Post<br />Read<br />Select<br />Get<br />Update<br />Update<br />Put<br />Delete<br />Delete<br />Delete<br />
    20. 20. URI Examples<br />GET<br />http://www.example.com/v1/employees<br />GET<br />http://www.example.com/v1/employees/1824<br />POST<br />http://www.example.com/v1/employees<br />PUT<br />http://www.example.com/v1/employees/1513<br />DELETE<br />http://www.example.com/v1/employees/1222<br />
    21. 21. REST Basics<br />The REST architecture was designed around a few key principles:<br /><ul><li> Use HTTP Methods (and Response Codes)
    22. 22. Be Stateless and Cacheable
    23. 23. Use Addressable Resources
    24. 24. Support the transfer of Representations</li></li></ul><li>Stateless and Cacheable<br /><ul><li>No State Stored on the Server
    25. 25. Every HTTP request executes in complete isolation on the server
    26. 26. Easier to scale because of GET method</li></li></ul><li>REST Basics<br />The REST architecture was designed around a few key principles:<br /><ul><li> Use HTTP Methods (and Response Codes)
    27. 27. Be Stateless and Cacheable
    28. 28. Use Addressable Resources
    29. 29. Support the transfer of Representations</li></li></ul><li>Resources<br /><ul><li>Any THING – person, concept, artifact
    30. 30. Anything you can point to
    31. 31. Explicit Request and Response – No State</li></li></ul><li>REST Basics<br />The REST architecture was designed around a few key principles:<br /><ul><li> Use HTTP Methods (and Response Codes)
    32. 32. Be Stateless and Cacheable
    33. 33. Addressable Resources
    34. 34. Support the transfer of Representations</li></li></ul><li>Representations<br /><ul><li>A serializable description of a Resource
    35. 35. Resources are modifiable through Representations
    36. 36. XML
    37. 37. JSON
    38. 38. Binary Formats (jpg, gif, mpeg)</li></li></ul><li>REST Pros<br />Cacheable<br />Scalable<br />Different Representations<br />Human Readable Results<br />Lightweight<br />
    39. 39. REST Cons<br />Must be HTTP<br />No Atomic Transactions<br />No Standards for security except HTTPS<br />No Standardized Discovery<br />
    40. 40. REST vs. SOAP<br />Unlike SOAP-based web services, there is no &quot;official&quot; standard for RESTful web service. <br />Though not a standard, a RESTful implementation uses standards like HTTP, URL, XML, GIF, etc. <br />
    41. 41. REST vs. SOAP<br />SOAP<br /><ul><li>Protocol
    42. 42. Verbose Payload
    43. 43. Envelope
    44. 44. Not easily readable
    45. 45. Requires Development Tools
    46. 46. Uses POST Method
    47. 47. Supports Transactions
    48. 48. Standardized Discovery
    49. 49. WSDL</li></ul>REST<br /><ul><li>Architecture
    50. 50. Lightweight Payload
    51. 51. Postcard
    52. 52. Human Readable Results
    53. 53. Easy to work with, Brower-testable
    54. 54. GET Method supports caching
    55. 55. No Transactions
    56. 56. Discovery
    57. 57. WADL?</li></li></ul><li>USING Rest<br />
    58. 58. USING REST<br />Think of a REST API as another data source<br />Details depend on the language, but there are common steps:<br /><ul><li>Serialize the representation (if PUT or POST)
    59. 59. Format the URI (parameters, variables)
    60. 60. Encode Authentication into the Header
    61. 61. Make Call
    62. 62. Deserialize Response</li></li></ul><li>USING REST<br />Three basic options for consuming RESTful APIs<br /><ul><li>Use the service’s toolkit (not always available)
    63. 63. Community-built library/wrapper
    64. 64. code.google.com
    65. 65. www.codeplex.com
    66. 66. Code your own implementation</li></li></ul><li>Community Built<br />Upside <br /><ul><li>Ready to use</li></ul>Downside<br /><ul><li>It’s not your code
    67. 67. You may be waiting for the library to become available.
    68. 68. Enterprise clients may have concerns</li></li></ul><li>Writing Your Own<br />Upside <br /><ul><li>You know the code</li></ul>Downside<br /><ul><li>Manual Discovery Process
    69. 69. Implementation can be tedious</li></li></ul><li>Tools<br />Tools for testing RESTful APIs<br /><ul><li>Curl
    70. 70. Eclipse Http4e
    71. 71. Fiddler
    72. 72. Your Browser (limited)</li></li></ul><li>WADL<br />
    73. 73. WADL<br />Web Application Discovery Language (WADL)<br />Created in 2005 by Marc Hadley of Sun Microsystems<br />Submitted to W3C on 8/31/2009<br />REST’s Answer to WSDL<br />Specification: https://wadl.dev.java.net/<br />
    74. 74. What WADL Gets You<br />Reduced Errors in Discovery<br />Opportunities for Code Generation<br />Spend more time building your application and less time implementing APIs<br />
    75. 75. So Where Is It?<br />Currently in Submission to W3C<br />API Providers are slow to adopt, so tool providers are slow to implement<br />There are projects underway to generate code from WADL, and at least one tool that helps in creating WADL<br />
    76. 76. WADL Demo<br />Project on code.google.com<br />Online Version: http://tomayac.de/rest-describe/latest/RestDescribe.html<br />
    77. 77. References<br />http://en.wikipedia.org/wiki/Representational_State_Transfer<br />http://weblogs.java.net/blog/mhadley/archive/2005/05/introducing_wad.html<br />http://blog.tomayac.de/index.php?date=2007-05-23<br />RESTful Web Services – Richardson, Ruby – O’Reilly Press <br />

    ×