Slides for my "Esto es Google" talk about REST, JSON and OAuth

2. REST, JSON and OAuth
Ikai Lan - @ikai
Esto es Google
August 9th, 2011

3. About the speaker
• Developer Relations at Google based out
of San Francisco, CA
• Focus: App Engine + Cloud
• Twitter: @ikai
• Google+: plus.ikailan.com

4. About the speaker
BIOGRAFÍA: Ikai es ingeniero de Desarrollo de
Programas en el motor de Google App. Antes de
Google, trabajó como ingeniero programador
construyendo aplicaciones para móviles y redes
sociales en LinkedIn. Ikai es un ávido de la
tecnología, consumiendo cantidades de material
acerca de nuevos lenguajes de programación,
estructuras o servicios. En sus ratos libres disfruta
de California, ganando concursos de karaoke
chino y jugando futbol de bandera. Actualmente
vive en el área de la Bahía de San Francisco,
donde agoniza viendo como su equipo favorito
explota temporada tras temporada.
English original: http://code.google.com/team/

5. About the speaker
BIOGRAFÍA: Ikai es ingeniero de Desarrollo de
Programas en el motor de Google App. Antes de
Google, trabajó como ingeniero programador
construyendo aplicaciones para móviles y redes
sociales en LinkedIn. Ikai es un ávido de la
tecnología, consumiendo cantidades de material
acerca de nuevos lenguajes de programación,
estructuras o servicios. En sus ratos libres disfruta
de California, ganando concursos de karaoke
chino y jugando futbol de bandera. Actualmente
vive en el área de la Bahía de San Francisco,
donde agoniza viendo como su equipo favorito
explota temporada tras temporada. !!!
English original: http://code.google.com/team/

6. This talk ...
• Is mostly language independent
• Can be very basic, but reviews are always
good

7. Agenda
• Learn about REST, JSON and OAuth
• Leave this talk understanding the
fundamentals of these standards

8. Tools of the trade
JSON
REST
OAuth

9. REST
REpresentational State Transfer

10. REST in action
Invoking remote methods via HTTP
GET /calendar/123
POST /calendar/456
PUT /calendar/888
DELETE /calendar/123/event/
678

11. HTTP verbs as actions
Verb Description
GET Reading an object
POST Creating a new object
PUT Editing an existing object
DELETE Deleting an object

12. Anatomy of a a REST
request
PUT /item/1 VERB and RESOURCE
Accept: application/json
someValue=someNewValue&secondValue
=678

13. Anatomy of a a REST
request
PUT /item/1
Accept: application/json
someValue=someNewValue&secondValue
Accepts header
=678

14. Anatomy of a a REST
request
PUT /item/1
Accept: application/json
someValue=someNewValue&secondValue
=678
Payload

15. Why REST?
• Builds on existing standards - almost all
languages with HTTP client are compatible
• Server side: maps very well to web
frameworks because of URI routing
• Simple to implement, simple to debug

16. JSON - the language of
the web
{
"version": "1.0",
"encoding": "UTF-8",
"author": [{
"name": {"$t": "Google Developer Calendar"},
"email": {"$t": "developer-calendar@google.com"}
}]
}

17. It’s just a Javascript
object
• Used in APIs to transfer data
• Can be nested
• Originally used for AJAX, now used for
server to server communications

18. vs. XML
{
"version": "1.0",
"encoding": "UTF-8",
"author": [{
"name": {"$t": "Google Developer Calendar"},
"email": {"$t": "developer-calendar@google.com"}
}]
}
<?xml version="1.0" encoding="UTF-8" ?>
<author>
<name>Google Developer Calendar</name>
<email>developer-calendar@google.com</
email>
</author>
</feed>

19. vs. XML
{
"version": "1.0",
"encoding": "UTF-8",
"author": [{
FIGHT!!!
"name": {"$t": "Google Developer Calendar"},
"email": {"$t": "developer-calendar@google.com"}
}]
}
<?xml version="1.0" encoding="UTF-8" ?>
<author>
<name>Google Developer Calendar</name>
<email>developer-calendar@google.com</
email>
</author>
</feed>

20. vs. XML
• XML is structured, provides validation
• JSON is more compact, easier to generate
and parse
• JSON maps very well to dictionary/hash
object in many languages

21. Python example
# Python 2.6
import json
data = { "key" : 123 }
json_value = json.dumps(data)
data_restored = json.loads(json_value)

22. Transport + protocol
What else do we need?

24. Authentication

26. Authorization

27. Your guest key for the
internet!

28. Some Google APIs

29. Some Google APIs
Contacts

30. Some Google APIs
Contacts Calendar

31. Some Google APIs
Contacts Calendar
Picasa
Web

32. Some Google APIs
Contacts Calendar
Picasa
YouTube
Web

33. Why not just ask for the
user’s password?

34. Because it’s bad.
• You train users to give their passwords to
third party sites
• Once you do this, users cannot revoke
third party site access without changing
password
• It’s really insecure and not flexible at all

35. SaaSy Payroll
Our example app that uses OAuth so
we can do things with Google APIs on
behalf of the user

36. The OAuth Dance!

37. The OAuth Dance!
User visits SaaSy Payroll

38. The OAuth Dance!
User visits SaaSy Payroll
SaaSy Payroll asks user to authorize data at Google

39. The OAuth Dance!
User visits SaaSy Payroll
SaaSy Payroll asks user to authorize data at Google
User grants data access to app

40. The OAuth Dance!
User visits SaaSy Payroll
SaaSy Payroll asks user to authorize data at Google
User grants data access to app
Google tells user to return to SaaSy Payroll with code

41. The OAuth Dance!
User visits SaaSy Payroll
SaaSy Payroll asks user to authorize data at Google
User grants data access to app
Google tells user to return to SaaSy Payroll with code
SaaSy Payroll asks Google for an access_token

42. The OAuth Dance!
User visits SaaSy Payroll
SaaSy Payroll asks user to authorize data at Google
User grants data access to app
Google tells user to return to SaaSy Payroll with code
SaaSy Payroll asks Google for an access_token
Google returns an access_token and a refresh_token

43. The Whole Flow (Continued)

44. The Whole Flow (Continued)
SaaSy Payroll accesses Google Calendar using access_token

45. The Whole Flow (Continued)
SaaSy Payroll accesses Google Calendar using access_token
Google returns protected data

46. The Whole Flow (Continued)
SaaSy Payroll accesses Google Calendar using access_token
Google returns protected data
Some time later

47. The Whole Flow (Continued)
SaaSy Payroll accesses Google Calendar using access_token
Google returns protected data
Some time later
SaaSy Payroll asks google for a new access_token

48. The Whole Flow (Continued)
SaaSy Payroll accesses Google Calendar using access_token
Google returns protected data
Some time later
SaaSy Payroll asks google for a new access_token
Google returns a new access_token

49. SaaSy Payroll

50. Access Control Grant

51. Payroll on the Calendar
Ikai’s Calendar

52. Calling an OAuth API
Application makes a HTTP GET or HTTP POST request to the server
containing the protected resource, including an Authorization header.
Additionally, the application specifies which user’s data it is trying to access
via a xoauth_requestor_id query parameter.
https://www.google.com/calendar/feeds/default/private
/full?xoauth_requestor_id=<email address>
Header:
Authorization: OAuth
oauth_version=”1.0”,
oauth_nonce=”1cbf231409dad9a2341856”,
oauth_timtestamp=”123456789”,
oauth_consumer_key=”<consumer_key>”,
oauth_signature_method=”HMAC-SHA1”,
oauth_signature=”1qz%2F%2BfwtsuO”

53. It’s all on top of
standard HTTP

54. Our goals met!
• We built an integrated, robust app that can
directly manipulate a user’s Google
Calendar
• Never have to ask user for Google
password - secure!

55. Recap
JSON OAuth
REST

56. REST - transport
standard on HTTP
GET /calendar/123
POST /calendar/456
PUT /calendar/888
DELETE /calendar/123/event/
678

57. JSON - the language of
the web
{
"version": "1.0",
"encoding": "UTF-8",
"author": [{
"name": {"$t": "Google Developer Calendar"},
"email": {"$t": "developer-calendar@google.com"}
}]
}

58. OAuth - third party
auth
• Valet key for the internet
• Key terms: OAuth dance, 3 legged oauth
• consumer key, consumer secret, access
token, access token secret

59. A recipe for great apps!

60. Questions?
• Read about OAuth: http://oauth.net/
• Google+: http://plus.ikailan.com
• Twitter: @ikai