Kirsten Jones, Technical Leader, Cisco Systems
   HTTP Overview   REST Web Services   OAuth Authentication
   HyperText Transfer Protocol   Used for conversations between web clients    and servers   Most of the internet uses ...
   Client sends a request       Method       URL       Headers       (sometimes) parameters       (sometimes) body ...
HTTP response codes for dummies. 50x: we fucked up. 40x: you fucked up. 30x: ask that dude over there. 20x: cool.Props...
   Chrome browser sends a request to Google     Method: GET     URL: http://www.google.com     Headers:      ▪ Accept:...
   Google sends a response     Headers:      ▪ Content-Length: 24716      ▪ Content-Encoding: gzip      ▪ Set-Cookie: NI...
   Macintosh: HTTPScoop    http://tuffcode.com/   Macintosh: Charles (supports SSL)    http://www.charlesproxy.com/   W...
Request
Headers
Request/Response
   Uses URL paths to define resources   Create, Read, Update, Delete     POST, GET, PUT, DELETE   Error Codes     HTT...
   Blog Info from Tumblr   GET (read)    http://api.tumblr.com/v2/blog/synedra.tumbl    er.com/info   Requires api_key ...
   Headers
   Request/Response
Status: 200Content:{"meta":   {"status":200, "msg":"OK” }, "response":{    "blog":{"title":"Untitled","posts":0,          ...
   Monitor application use   Know which users are making requests   Prevent DDOS attacks on the system
 Used by many APIs Each application gets a consumer key and secret Authentication server handles authentication Each u...
   REST web services call adds verification    signature to each request   Query parameters     Authorization header  ...
   Signature is generated based on       URL       Parameters       Consumer key       User token   http://api.linke...
   Request
   Headers (nothing special)
   Request/Response
   Signature is generated based on       URL       Parameters       Consumer key       User token URL is unchanged: ...
   No authorization parameters
   Authorization is in the header
   Request/response works the same
   How to use PECL OAuth to sign API requests   http://pecl.php.net/package/oauth   Quick walkthrough to understand pro...
   First step in OAuth: Get a request token for    this authorization session   OAuth library handles signing the request
   Second step: Send the user to the server to    authorize your application   After the user authorizes your    applica...
   Third step: Use the verifier and the request    token to get an access token   This is a long lived token
   Make an API call using the OAuth library   The library handles the signature generation
   HTTP: Hypertext Transfer Protocol   REST: REpresentational State Transfer   OAuth: Authentication
Demystifying REST
Upcoming SlideShare
Loading in...5
×

Demystifying REST

2,849

Published on

DEMYSTIFYING REST

Kirsten Jones
REST web services are everywhere! It seems like everything you want is available via a web service, but getting started with one of these web services can be overwhelming – and debugging the interactions bewilders some of the smartest developers I know. In this talk, I will talk about HTTP, how it works, and how to watch and understand the traffic between your system and the server. From there I’ll proceed to REST – how REST web services layer on top of HTTP and how you can expect a REST web service to behave. We’ll go over how to monitor and understand requests and responses for these services. Once we’ve covered that, I’ll talk about how OAuth is used for authentication in the framework of a REST application. PHP code samples will be shown for interacting with an OAuth REST web service, and I will cover http monitoring tools for multiple OS’s. When you’re done with this talk you’ll understand enough about REST web services to be able to get started confidently, and debug many of the common issues you may encounter.

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

No Downloads
Views
Total Views
2,849
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
31
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Demystifying REST

  1. 1. Kirsten Jones, Technical Leader, Cisco Systems
  2. 2.  HTTP Overview REST Web Services OAuth Authentication
  3. 3.  HyperText Transfer Protocol Used for conversations between web clients and servers Most of the internet uses HTTP Supports verbs for GET, PUT, POST, DELETE Query parameter framework
  4. 4.  Client sends a request  Method  URL  Headers  (sometimes) parameters  (sometimes) body Server replies with a response  Content  Status  Headers
  5. 5. HTTP response codes for dummies. 50x: we fucked up. 40x: you fucked up. 30x: ask that dude over there. 20x: cool.Props to @DanaDanger for that one
  6. 6.  Chrome browser sends a request to Google  Method: GET  URL: http://www.google.com  Headers: ▪ Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 ▪ Accept-Language: en-US,en;q=0.8 ▪ Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 ▪ Connection: keep-alive ▪ User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19 ▪ Accept-Encoding: gzip,deflate,sdch ▪ Cookie: NID=59=EudJ2a15ql8832PCysQA0qchtuvGWMoA7rkp79VpIYAQ8- j42IO17LFudCYNMXm9l6SHcu3YgrGRCdrRCyM468xPZaOek4Pi- AXQ8eARqU1SGYx6y7_9LW-c3HHb-vs2; PREF=ID=994f8de0e8b39a5b:U=237805f1f710dc73:FF=0:TM=1336752507:LM=13 36752509:S=W0Hha7x4czdXp51U ▪ Host: www.google.com
  7. 7.  Google sends a response  Headers: ▪ Content-Length: 24716 ▪ Content-Encoding: gzip ▪ Set-Cookie: NID=59=F48kbwfwOi-qCHJyrnMSUlDBVxK- ZVKZpq5B5jttt_25IRN4lS-0rQcVttq- dnOIlQzafw1i4HPQAO0RpZ7NuC0WCKWta7SYoekx0--YGf2zIFZ9VXIKS- _UEaOH9iBe; expires=Sat, 10-Nov-2012 21:26:46 GMT; path=/; domain=.google.com; HttpOnly ▪ Expires: -1 ▪ Server: gws ▪ X-XSS-Protection: 1; mode=block ▪ Cache-Control: private, max-age=0 ▪ X-Frame-Options: SAMEORIGIN ▪ Content-Type: text/html; charset=UTF-8 ▪ Date: Fri, 11 May 2012 21:26:46 GMT  Content: A bunch of HTML  Status: 200
  8. 8.  Macintosh: HTTPScoop http://tuffcode.com/ Macintosh: Charles (supports SSL) http://www.charlesproxy.com/ Windows: Fiddler http://www.fiddler2.com/fiddler2/ Unix (or Mac): Wireshark (X11) http://www.wireshark.org/
  9. 9. Request
  10. 10. Headers
  11. 11. Request/Response
  12. 12.  Uses URL paths to define resources Create, Read, Update, Delete  POST, GET, PUT, DELETE Error Codes  HTTP Status Codes Request parameters  Query parameters Response types and configuration  Headers
  13. 13.  Blog Info from Tumblr GET (read) http://api.tumblr.com/v2/blog/synedra.tumbl er.com/info Requires api_key sent as parameter
  14. 14.  Headers
  15. 15.  Request/Response
  16. 16. Status: 200Content:{"meta": {"status":200, "msg":"OK” }, "response":{ "blog":{"title":"Untitled","posts":0, "name":"synedra", "url":"http://synedra.tumblr.com/", "updated":0, "description":"","ask":false,"likes":0}}}
  17. 17.  Monitor application use Know which users are making requests Prevent DDOS attacks on the system
  18. 18.  Used by many APIs Each application gets a consumer key and secret Authentication server handles authentication Each user of an application gets a unique user token and secret Supports tracking of application/member use of the API Allows users to protect username/password Industry standard – libraries for most programming languages
  19. 19.  REST web services call adds verification signature to each request Query parameters  Authorization header Secrets are used to create signature Authentication server checks signature to verify that it was created using shared secrets If authentication succeeds, request is processed by API server
  20. 20.  Signature is generated based on  URL  Parameters  Consumer key  User token http://api.linkedin.com/v1/people/url=http%3A%2F%2Fw ww.linkedin.com%2Fin%2Fsynedra?oauth_body_hash=2j mj7l5rSw0yVb%2FvlWAYkK%2FYBwk%3D&oauth_nonce =6283929&oauth_timestamp=1336775605&oauth_consu mer_key=***KEY***&oauth_signature_method=HMAC- SHA1&oauth_version=1.0&oauth_token=***TOKEN*** &oauth_signature=CqHiZI6tI3pQGe5a0vVgoT0822A%3D
  21. 21.  Request
  22. 22.  Headers (nothing special)
  23. 23.  Request/Response
  24. 24.  Signature is generated based on  URL  Parameters  Consumer key  User token URL is unchanged: http://api.linkedin.com/v1/people/~/shares Authorization header has oauth stuff: OAuth realm="http://api.linkedin.com", oauth_body_hash="JtgCKBurLIPLM4dXkn2E3lgrfI4%3D", oauth_nonce="60723468", oauth_timestamp="1336776657", oauth_consumer_key=”***KEY***", oauth_signature_method="HMAC-SHA1", oauth_version="1.0", oauth_token=”***TOKEN***", oauth_signature="8iWVpIK3LhRbu8JPf2gzC1YxQy4%3D"
  25. 25.  No authorization parameters
  26. 26.  Authorization is in the header
  27. 27.  Request/response works the same
  28. 28.  How to use PECL OAuth to sign API requests http://pecl.php.net/package/oauth Quick walkthrough to understand process (but this talk is not about Oauth)
  29. 29.  First step in OAuth: Get a request token for this authorization session OAuth library handles signing the request
  30. 30.  Second step: Send the user to the server to authorize your application After the user authorizes your application, the server returns a verification code for you to use
  31. 31.  Third step: Use the verifier and the request token to get an access token This is a long lived token
  32. 32.  Make an API call using the OAuth library The library handles the signature generation
  33. 33.  HTTP: Hypertext Transfer Protocol REST: REpresentational State Transfer OAuth: Authentication
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×