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.

of

Scalable Reliable Secure REST Slide 1 Scalable Reliable Secure REST Slide 2 Scalable Reliable Secure REST Slide 3 Scalable Reliable Secure REST Slide 4 Scalable Reliable Secure REST Slide 5 Scalable Reliable Secure REST Slide 6 Scalable Reliable Secure REST Slide 7 Scalable Reliable Secure REST Slide 8 Scalable Reliable Secure REST Slide 9 Scalable Reliable Secure REST Slide 10 Scalable Reliable Secure REST Slide 11 Scalable Reliable Secure REST Slide 12 Scalable Reliable Secure REST Slide 13 Scalable Reliable Secure REST Slide 14 Scalable Reliable Secure REST Slide 15 Scalable Reliable Secure REST Slide 16 Scalable Reliable Secure REST Slide 17 Scalable Reliable Secure REST Slide 18 Scalable Reliable Secure REST Slide 19 Scalable Reliable Secure REST Slide 20 Scalable Reliable Secure REST Slide 21 Scalable Reliable Secure REST Slide 22 Scalable Reliable Secure REST Slide 23 Scalable Reliable Secure REST Slide 24 Scalable Reliable Secure REST Slide 25 Scalable Reliable Secure REST Slide 26 Scalable Reliable Secure REST Slide 27 Scalable Reliable Secure REST Slide 28 Scalable Reliable Secure REST Slide 29 Scalable Reliable Secure REST Slide 30 Scalable Reliable Secure REST Slide 31 Scalable Reliable Secure REST Slide 32 Scalable Reliable Secure REST Slide 33 Scalable Reliable Secure REST Slide 34 Scalable Reliable Secure REST Slide 35 Scalable Reliable Secure REST Slide 36 Scalable Reliable Secure REST Slide 37 Scalable Reliable Secure REST Slide 38 Scalable Reliable Secure REST Slide 39 Scalable Reliable Secure REST Slide 40 Scalable Reliable Secure REST Slide 41 Scalable Reliable Secure REST Slide 42 Scalable Reliable Secure REST Slide 43 Scalable Reliable Secure REST Slide 44 Scalable Reliable Secure REST Slide 45 Scalable Reliable Secure REST Slide 46 Scalable Reliable Secure REST Slide 47 Scalable Reliable Secure REST Slide 48 Scalable Reliable Secure REST Slide 49 Scalable Reliable Secure REST Slide 50 Scalable Reliable Secure REST Slide 51 Scalable Reliable Secure REST Slide 52 Scalable Reliable Secure REST Slide 53 Scalable Reliable Secure REST Slide 54 Scalable Reliable Secure REST Slide 55 Scalable Reliable Secure REST Slide 56 Scalable Reliable Secure REST Slide 57 Scalable Reliable Secure REST Slide 58
Upcoming SlideShare
Understanding REST-Based Services: Simple, Scalable, and Platform Independent
Next
Download to read offline and view in fullscreen.

27 Likes

Share

Download to read offline

Scalable Reliable Secure REST

Download to read offline

Related Books

Free with a 30 day trial from Scribd

See all

Scalable Reliable Secure REST

  1. 1. Scalable, Reliable, and Secure RESTful HTTP A practical guide to building to HTTP based services
  2. 2. Today’s talk <ul><li>Goal: learn how to build services with HTTP in a reliable, secure, and scalable fashion. </li></ul>
  3. 3. What this talk is NOT
  4. 4. What is REST? <ul><li>Representation State Transfer </li></ul><ul><li>Roy Fielding coined the term for his thesis which sought to provide the architectural basis for HTTP </li></ul>
  5. 6. Resources, resources, resources <ul><li>Everything is a resource </li></ul><ul><li>Resources are addressable via URI s </li></ul><ul><li>Resources are self descriptive </li></ul><ul><ul><li>Typically through content types (“application/xml”) and sometimes the resource body (i.e. an XML QName) </li></ul></ul><ul><li>Resources are stateless </li></ul><ul><li>Resources are manipulated via verbs and the uniform interface </li></ul>
  6. 7. The Uniform Interface
  7. 8. Hypertext and linkability <ul><li>We don’t want “keys”, we want links! </li></ul><ul><li>Resources are hypertext </li></ul><ul><ul><li>Hypertext is just data with links to other resources </li></ul></ul><ul><li>Data model refers to other application states via links </li></ul><ul><li>This is possible because of the uniform interface! No need to know different ways to get different types of entities! </li></ul><ul><li>Client can simply navigate to different resources </li></ul>
  8. 9. REST & HTTP <ul><li>REST defines the architectural style of HTTP </li></ul><ul><li>We’ll discuss RESTful principles in relation to HTTP specifically as we explore </li></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Security </li></ul></ul>
  9. 10. Our Starting Point
  10. 11. Reliability through Idempotency
  11. 12. Idempotent Operations
  12. 13. Some Basic Scenarios: <ul><li>Getting resources </li></ul><ul><li>Deleting resources </li></ul><ul><li>Updating a resource </li></ul><ul><li>Creating a resource </li></ul>
  13. 14. Getting a resource <ul><li>GET is SAFE </li></ul><ul><li>If original GET fails, just try, try again </li></ul>
  14. 15. Updating a resource Server Client
  15. 16. Deleting a resource Server Client
  16. 17. Creating Resources <ul><li>HTTP/1.1 201 Created </li></ul><ul><li>Date: … </li></ul><ul><li>Content-Length: 0 </li></ul><ul><li>Location: http://acme.com/entries/1 </li></ul><ul><li>… </li></ul>Server Client Client Server HTTP/1.1 200 OK … POST /entries Host: acme.com … PUT /entries/1 Host: acme.com Content-Type: … Content-Length: … Some data…
  17. 18. Creating Resources <ul><li>IDs which are not used can be </li></ul><ul><ul><li>Ignored </li></ul></ul><ul><ul><li>Expired </li></ul></ul><ul><li>Another option: have the client generate a unique ID and PUT to it straight away </li></ul><ul><ul><li>They’re liable to screw it up though </li></ul></ul>
  18. 19. Problem: Firewalls <ul><li>Many firewalls do not allow PUT, DELETE </li></ul><ul><li>You might want to allow other ways of specifying a header: </li></ul><ul><ul><li>Google: X-HTTP-Method-Override: PUT </li></ul></ul><ul><ul><li>Ruby: ?method=PUT </li></ul></ul>
  19. 20. Scalability <ul><li>ETags, Caching, Content-Types, URLs, and more </li></ul>
  20. 21. Scaling HTTP <ul><li>Statelessness and scalability </li></ul><ul><li>ETags/LastModified </li></ul><ul><li>Caching and proxies </li></ul><ul><li>HEAD </li></ul><ul><li>“ Expect: 100-continue” </li></ul><ul><li>Batch operations </li></ul><ul><li>Transactions & Compensation </li></ul>
  21. 22. Stateless client/server approach <ul><li>All communication is stateless </li></ul><ul><li>Session state is kept on the Client! </li></ul><ul><ul><li>Client is responsible for transitioning to new states </li></ul></ul><ul><ul><li>States are represented by URIs </li></ul></ul><ul><li>Improves: </li></ul><ul><ul><li>Visibility </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Scalability </li></ul></ul>
  22. 23. ETag Header <ul><li>Resources may return an ETag header when it is accessed </li></ul><ul><li>On subsequent retrieval of the resource, Client sends this ETag header back </li></ul><ul><li>If the resource has not changed (i.e. the ETag is the same), an empty response with a 304 code is returned </li></ul><ul><li>Reduces bandwidth/latency </li></ul>
  23. 24. ETag Example <ul><li>HTTP/1.1 200 OK </li></ul><ul><li>Date: … </li></ul><ul><li>ETag: &quot;3e86-410-3596fbbc&quot; </li></ul><ul><li>Content-Length: 1040 </li></ul><ul><li>Content-Type: text/html </li></ul><ul><li>… </li></ul>Server Client Client Server HTTP/1.1 304 Not Modified Date: … ETag: &quot;3e86-410-3596fbbc&quot; Content-Length: 0… GET /feed.atom Host: www.acme.com … GET /feed.atom If-None-Match: &quot;3e86-410-3596fbbc&quot; Host: www.acme.com …
  24. 25. LastModified Example <ul><li>HTTP/1.1 200 OK </li></ul><ul><li>Date: … </li></ul><ul><li>Last-Modified: Sat, 29 Oct 1994 19:43:31 GMT </li></ul><ul><li>Content-Length: 1040 </li></ul><ul><li>Content-Type: text/html </li></ul><ul><li>… </li></ul>Client Server HTTP/1.1 304 Not Modified Date: … Last-Modified: Sat, 29 Oct 1994 19:43:31 GMT Content-Length: 0 GET /feed.atom Host: www.acme.com … GET /feed.atom If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT Host: www.acme.com …
  25. 26. Scalability through Caching <ul><li>A.k.a. “cache the hell out of it” </li></ul><ul><li>Reduce latency, network traffic, and server load </li></ul><ul><li>Types of cache: </li></ul><ul><ul><li>Browser </li></ul></ul><ul><ul><li>Proxy </li></ul></ul><ul><ul><li>Gateway </li></ul></ul>
  26. 27. How Caching Works <ul><li>A resource is eligible for caching if: </li></ul><ul><ul><li>The HTTP response headers don’t say not to cache it </li></ul></ul><ul><ul><li>The response is not authenticated or secure </li></ul></ul><ul><ul><li>No ETag or LastModified header is present </li></ul></ul><ul><ul><li>The cache representation is fresh </li></ul></ul><ul><li>From: http://www.mnot.net/cache_docs/ </li></ul>
  27. 28. Is your cache fresh? <ul><li>Yes, if: </li></ul><ul><ul><li>The expiry time has not been exceeded </li></ul></ul><ul><ul><li>The representation was LastModified a relatively long time ago </li></ul></ul><ul><li>If its stale, the remote server will be asked to validate if the representation is still fresh </li></ul>
  28. 29. Scalability through URLs and Content-Types <ul><li>Information about where the request is destined is held outside the message: </li></ul><ul><ul><li>Content-Type </li></ul></ul><ul><ul><ul><li>application/purchase-order+xml </li></ul></ul></ul><ul><ul><ul><li>mage/jpeg </li></ul></ul></ul><ul><ul><li>URL </li></ul></ul><ul><ul><li>Other headers </li></ul></ul><ul><li>Allows easy routing to the appropriate server with little overhead </li></ul>
  29. 30. HEAD <ul><li>Allows you to get meta data about a resource without getting the resource itself </li></ul><ul><li>Identical to GET, except no body is sent </li></ul><ul><li>Uses: </li></ul><ul><ul><li>Testing that a resource is available </li></ul></ul><ul><ul><li>Testing link validity </li></ul></ul><ul><ul><li>Learning when a resource was last modified </li></ul></ul>
  30. 31. 100 Continue <ul><li>Allows client to determine if server is willing to accept a request based on request headers </li></ul><ul><li>It may be highly inefficient to send the full request if the server will reject it </li></ul>
  31. 32. 100 Continue
  32. 33. Transactions <ul><li>The web is NOT designed for transactions </li></ul><ul><ul><li>Client is responsible for committing/rolling back transactions, and client may not fulfill responsibilities </li></ul></ul><ul><ul><li>Transactions can take too long over the web and tie up important resources </li></ul></ul><ul><li>In general, it is much better to build in application specific compensation for distributed services </li></ul><ul><li>See the paper: Life Beyond Transactions by Pat Helland </li></ul>
  33. 34. So you really want transactions… <ul><li>People sometimes use HTTP for transactions </li></ul><ul><li>Notable example: SVN </li></ul><ul><li>It is possible to model a resource as a transaction </li></ul><ul><ul><li>POST – create a new transaction </li></ul></ul><ul><ul><li>PUT – send “commit” state to transaction </li></ul></ul><ul><ul><li>DELETE – rollback the transaction </li></ul></ul>
  34. 35. Batch Operations <ul><li>How do we manipulate multiple resource states at the same time? </li></ul><ul><li>Options: </li></ul><ul><ul><li>Use HTTP connection pipelining </li></ul></ul><ul><ul><ul><li>Broken by some firewalls </li></ul></ul></ul><ul><ul><li>POST </li></ul></ul><ul><ul><ul><li>GData does this, but has received a very cold reception from the community </li></ul></ul></ul>
  35. 36. Security
  36. 37. Question #1 <ul><li>What are your goals & requirements? </li></ul><ul><ul><li>Authentication? </li></ul></ul><ul><ul><li>Authorization? </li></ul></ul><ul><ul><li>Privacy? </li></ul></ul><ul><ul><li>Integrity? </li></ul></ul><ul><ul><li>Single sign on? </li></ul></ul>
  37. 38. Tools at our disposal <ul><li>HTTP Authentication </li></ul><ul><li>SSL </li></ul><ul><li>XML Signature & Encryption </li></ul><ul><li>OpenID </li></ul><ul><li>Others: </li></ul><ul><ul><li>SAML, Cardspace… </li></ul></ul>
  38. 39. HTTP Authentication Basics <ul><li>Basic Authentication </li></ul><ul><ul><li>Username & Password passed in plain text </li></ul></ul><ul><li>Digest </li></ul><ul><ul><li>MD5 has of username & password is created </li></ul></ul><ul><li>Sent with every request </li></ul><ul><ul><li>Remember – statelessness? </li></ul></ul>
  39. 40. SSL and Public Key Cryptography <ul><li>SSL/TLS defines a process to encrypt/secure transports </li></ul>
  40. 41. How SSL works Client Server Sends random number encrypted with server’s public key.
  41. 42. How SSL works Client Server Server sends random number to client. Can be unencrypted since Client may not have public key.
  42. 43. How SSL works Client Server Server and Client compute a shared secret using the negotiated hash algorithm. 94AB134… 94AB134…
  43. 44. How SSL works Client Server Communication is encrypted using the new shared secret & symmetric cryptography
  44. 45. Client Authentication <ul><li>Server can authenticate the Client using it’s public key as well </li></ul><ul><li>Requires key distribution </li></ul><ul><ul><li>Server side must import every client public key into it’s keystore </li></ul></ul>
  45. 46. Limitations of SSL <ul><li>Does not work well with intermediaries </li></ul><ul><ul><li>If you have a gateway handling SSL, how do you actually get the certificate information? </li></ul></ul><ul><li>Limited ability for other authentication tokens beyond those of HTTP Auth </li></ul><ul><ul><li>i.e. SAML </li></ul></ul><ul><ul><li>Some implementations support NTLM (Commons HTTPClient) </li></ul></ul>
  46. 47. OpenID <ul><li>“ provides a way to prove that an End User owns an Identity URL” </li></ul><ul><li>An attempt at single sign on. Your identity is your URL </li></ul><ul><li>Provides no information about who the actual person/entity is </li></ul>
  47. 48. XML Signature & Encryption <ul><li>Provide message level security when needed </li></ul><ul><li>Limited support across languages </li></ul><ul><ul><li>Mostly Java & .NET </li></ul></ul><ul><li>Allows other types of authentication mechanisms beyond just SSL </li></ul>
  48. 49. An XML digital signature <ul><li>< ds:Signature > </li></ul><ul><li>< ds:SignedInfo > </li></ul><ul><li>< ds:CanonicalizationMethod Algorithm = </li></ul><ul><li>&quot;http://www.w3.org/2001/10/xml-exc-c14n#&quot; /> </li></ul><ul><li>< ds:SignatureMethod Algorithm = </li></ul><ul><li>&quot;http://www.w3.org/2000/09/xmldsig#rsa-sha1&quot; /> </li></ul><ul><li>< ds:Reference URI = &quot;#mySignedElement&quot; > </li></ul><ul><li>< ds:Transforms > </li></ul><ul><li>< ds:Transform Algorithm = &quot;http://www.w3.org/2001/10/xml-exc-c14n#&quot; /> </li></ul><ul><li></ ds:Transforms > </li></ul><ul><li>< ds:DigestMethod Algorithm = </li></ul><ul><li>&quot;http://www.w3.org/2000/09/xmldsig#sha1&quot; /> </li></ul><ul><li>< ds:DigestValue > EULddytSo1... </ ds:DigestValue > </li></ul><ul><li></ ds:Reference > </li></ul><ul><li></ ds:SignedInfo > </li></ul><ul><li>< ds:SignatureValue > </li></ul><ul><li>BL8jdfToEb1l/vXcMZNNjPOV... </li></ul><ul><li></ ds:SignatureValue > </li></ul><ul><li>< ds:KeyInfo > </li></ul><ul><li>… </li></ul><ul><li></ ds:KeyInfo > </li></ul><ul><li></ ds:Signature > </li></ul>
  49. 50. HTTP Security Limitations <ul><li>For non XML data, there is no standard way to do </li></ul><ul><ul><li>Message signing </li></ul></ul><ul><ul><li>Non repudiation </li></ul></ul><ul><ul><li>Multifactor authentication </li></ul></ul><ul><ul><li>Token exchange </li></ul></ul>
  50. 51. Other Thoughts
  51. 52. Consider using Atom Publishing Protocol <ul><li>Atom: a format for syndication </li></ul><ul><ul><li>Describes “lists of related information” – a.k.a. feeds </li></ul></ul><ul><ul><li>Feeds are composed of entries </li></ul></ul><ul><li>User Extensible </li></ul><ul><li>More generic than just blog stuff </li></ul>
  52. 53. Atom Publishing Protocol <ul><li>RESTful protocol for building services </li></ul><ul><li>Create, edit, delete entries in a collection </li></ul><ul><li>Extensible Protocol </li></ul><ul><ul><li>Paging extensions </li></ul></ul><ul><ul><li>GData </li></ul></ul><ul><ul><li>Opensearch </li></ul></ul><ul><li>Properly uses HTTP so can be scalable, reliable and secure </li></ul>
  53. 54. Why you should use APP for your app <ul><li>Provides ubiquitous elements which have meaning across all contexts </li></ul><ul><li>You can leverage existing solutions for security </li></ul><ul><ul><li>HTTP Auth, WSSE, Google Login, XML Sig & Enc </li></ul></ul><ul><li>Eliminates the need for you to write a lot of server/client code </li></ul><ul><ul><li>ETags, URLs, etc are all handled for you </li></ul></ul><ul><li>Integrates seamlessly with non-XML data </li></ul><ul><li>There are many APP implementations and they are known to work well together </li></ul>
  54. 55. What other tools are available for building RESTful applications? <ul><li>HTTPD of course </li></ul><ul><li>Java </li></ul><ul><ul><li>Servlets </li></ul></ul><ul><ul><li>Restlets </li></ul></ul><ul><ul><li>Spring MVC </li></ul></ul><ul><ul><li>CXF </li></ul></ul><ul><ul><li>Jersey (JSR 311 reference imlementation) </li></ul></ul><ul><li>Ruby on Rails </li></ul><ul><li>Python’s Django </li></ul><ul><li>Javascript’s XMLHttpRequest  </li></ul><ul><li>Abdera </li></ul>
  55. 56. Limitations <ul><li>HTTP is NOT an RPC or message passing system </li></ul><ul><ul><li>Not ideal for sending event based messages </li></ul></ul><ul><ul><li>May have performance constraints for asynchronous messaging that JMS/others may not have </li></ul></ul><ul><li>Security Standards </li></ul><ul><ul><li>Most people will just use SSL, but… </li></ul></ul><ul><ul><li>Exchanging other types of authentication tokens is not possible unless they are custom HTTP headers </li></ul></ul><ul><ul><li>No standard way to establish trust relationships beside certificate hierarchies/webs </li></ul></ul>
  56. 57. Conclusions <ul><li>HTTP Provides many tools/properties for us to build scalable, reliable, secure systems: </li></ul><ul><ul><li>Idempotent and safe methods </li></ul></ul><ul><ul><li>ETags/LastModified </li></ul></ul><ul><ul><li>Hypertext </li></ul></ul><ul><ul><li>Caching </li></ul></ul><ul><ul><li>URLs & Content Types </li></ul></ul><ul><ul><li>SSL </li></ul></ul><ul><li>Beyond HTTP </li></ul><ul><ul><li>Atom Publishing Protocol </li></ul></ul><ul><ul><li>XML Signatures & Encryption </li></ul></ul><ul><ul><li>OpenID </li></ul></ul><ul><ul><li>Much more… </li></ul></ul>
  57. 58. Questions? <ul><li>Blog: http://netzooid.com/blog </li></ul><ul><li>Email: dan.diephouse@mulesource.com </li></ul><ul><li>Resources: </li></ul><ul><ul><li>RFC2616: http://www.faqs.org/rfcs/rfc2616.html </li></ul></ul><ul><ul><li>RESTful Web Services (Richardson, Ruby, DHH) </li></ul></ul>
  • bhushan985099

    Sep. 5, 2017
  • Gudimetla

    May. 21, 2016
  • hczcolin

    Apr. 17, 2016
  • DavidlvarezConde

    Mar. 4, 2016
  • sabithvm

    Dec. 10, 2015
  • JenHsuanHsieh

    Nov. 8, 2015
  • gokeepapa

    Jul. 9, 2014
  • CarlosGalue

    Oct. 3, 2013
  • nickolayrusev

    Oct. 2, 2013
  • talltk

    Jul. 25, 2013
  • ProDG911

    Jun. 17, 2013
  • iambigd

    Jun. 2, 2013
  • nikescar

    Apr. 9, 2013
  • FranciscoVianna

    Feb. 7, 2013
  • nightzen

    Apr. 9, 2012
  • nicolaiarocci

    Jan. 15, 2012
  • alexverdyan

    Nov. 28, 2011
  • gianfragolo

    May. 15, 2011
  • ahtimsir

    Jan. 19, 2011
  • rafaelcarneiro

    Nov. 10, 2010

Views

Total views

20,175

On Slideshare

0

From embeds

0

Number of embeds

94

Actions

Downloads

426

Shares

0

Comments

0

Likes

27

×