RESTing in the ALPS Mike Amundsen's Presentation from QCon London 2013

3,897 views

Published on

Generic Hypermedia and Domain-Specific APIs: RESTing in the ALPS
Track: Building Web APIs: Opening & Linking your Data / Time: Thursday 15:40 - 16:30 / Location: Fleming Room

Hypermedia API is the new catch-phrase, but what is a Hypermedia API? Does this trend lead us toward a debilitating explosion of media types? Can we really create successful hypermedia APIs or is this just the latest hype?

Recently a number of new media types that offer hypermedia support have come into use on the Web including HAL, Collection+JSON, Siren, and more. However, these new designs are not designed to communicate application-specific information (e.g. accounting, microblogging, etc.) in a standard way. Is there a way to resolve this problem?

Drawing on the experience of Dublin Core, Microformats, Activity Streams, and other similar approaches, this talk describes the ALPS (Application-Level Profile Semantics) standard; a way to define the data and workflow details for a Web application and apply these details consistently regardless of the media type in use. Working examples in the talk also show how this standardized definition can make designing, implementing, documenting, and maintaining Web APIs easier and more consistent across multiple media types.

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

No Downloads
Views
Total views
3,897
On SlideShare
0
From Embeds
0
Number of Embeds
110
Actions
Shares
0
Downloads
35
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

RESTing in the ALPS Mike Amundsen's Presentation from QCon London 2013

  1. 1. RESTing in the ALPSGeneric Hypermedia and Domain-Specific APIs @mamund Mike Amundsen Principal API Architect, Layer 7 Technologies
  2. 2. A simple story In three parts...
  3. 3. The bona fides How we got here...
  4. 4. The confession I left some stuff out...
  5. 5. Where I make amends The payoff
  6. 6. Ok, lets begin...
  7. 7. How we got here... The bona fides
  8. 8. Lets start with a quote from 2002
  9. 9. Fielding and Taylor, 2002 "REST provides [this] by focusing on a shared understanding of data types with metadata..."
  10. 10. That phrase struck me.
  11. 11. It has become a prime motivator for me.
  12. 12. focusing
  13. 13. focusing on
  14. 14. focusing onshared understanding
  15. 15. shared understanding
  16. 16. How do we share understanding on the Web?
  17. 17. protocols
  18. 18. http ftpsmtp protocols dns ws xmpp
  19. 19. But thats not all...
  20. 20. Fielding & Taylor, 2002 "REST components communicate by transferring a representation of the data in a format matching one of an evolving set of standard data types..."
  21. 21. html csvhal standard data types atomjson Cj
  22. 22. html csvhalregistered media types atomjson Cj
  23. 23. html csvhal messages atomjson Cj
  24. 24. We share understanding via messages.
  25. 25. Description
  26. 26. Discovery
  27. 27. Hypermedia
  28. 28. These messages tell us whatprotocol actions are possible.
  29. 29. These messages tell us whatprotocol actions are possible.
  30. 30. How is this done in a message?
  31. 31. affordances
  32. 32. hypermediaaffordances
  33. 33. protocolhypermediaaffordances
  34. 34. Back in 2010, I called those...
  35. 35. H-Factors
  36. 36. H-Factors
  37. 37. H-Factors Identify nine features for sharing understanding about protocol actions.
  38. 38. H-Factors
  39. 39. H-Factors
  40. 40. H-Factors
  41. 41. H-Factors Identify the affordances
  42. 42. H-Factors
  43. 43. H-Factors Categorize them.
  44. 44. H-Factors
  45. 45. H-Factors For lots of media type designs.
  46. 46. H-Factors
  47. 47. H-Factors
  48. 48. H-Factors
  49. 49. H-Factors
  50. 50. H-Factors This gives us a tool for lots of tasks...
  51. 51. H-Factors We can analyze existing designs
  52. 52. H-Factors We can categorize types for best fit implementations
  53. 53. H-Factors We can use H-Factors to model prototype designs
  54. 54. H-Factors
  55. 55. H-Factors We now have a shared understanding about protocol affordances
  56. 56. H-Factors
  57. 57. H-Factors
  58. 58. H-Factors And this is all good.
  59. 59. H-Factors But...
  60. 60. H-Factors Theres a problem here.
  61. 61. H-Factors An important piece is missing.
  62. 62. H-Factors There is a "gap" between theory and practice
  63. 63. H-Factors There is a "gap" between H-Factors and "the real world"
  64. 64. I ignored this "gap" when identifying H-Factors.
  65. 65. I side-stepped the "gap" in the last book.
  66. 66. H-Factors
  67. 67. And this "gap" is a key theme in the next book.
  68. 68. H-Factors Yep, you might say...
  69. 69. I left some stuff out. The confession
  70. 70. The confession I ignored the "hard" parts ...
  71. 71. The confession
  72. 72. The confession What are those?
  73. 73. The confession
  74. 74. The confession Theyre rather specific.
  75. 75. The confession
  76. 76. The confession affordances?
  77. 77. The confession
  78. 78. The confession Well, they are not protocol affordances
  79. 79. The confession I call them application affordances
  80. 80. The confession But there is another name for these...
  81. 81. Vocabularies Srsly?
  82. 82. Vocabularies On the Web, representations contain protocol AND application affordances
  83. 83. Vocabularies We share understanding at the application-level, too.
  84. 84. Vocabularies Well, "we" means us humans.
  85. 85. Vocabularies Do we share app-level understanding?
  86. 86. Vocabularies How about now?
  87. 87. Vocabularies How about now?
  88. 88. Vocabularies Human app-level affordances
  89. 89. Vocabularies Machine app-level affordances
  90. 90. Vocabularies Of course, weve known this for quite a while.
  91. 91. Vocabularies schema.org dublin core VoID There has been quite a bit of work on vocabularies activity streamsmicroformats
  92. 92. Vocabularies Vocabularies can provide shared understanding of the application-specific affordances
  93. 93. Vocabularies And this is all good.
  94. 94. Vocabularies But...
  95. 95. Vocabularies Theres a problem here.
  96. 96. Vocabularies An important piece is missing.
  97. 97. Vocabularies There is a "gap" between theory and practice
  98. 98. Vocabularies There is a "gap"between Vocabularies and "the real world"
  99. 99. Vocabularies state Vocabularies only model the "what"
  100. 100. Vocabularies state Vocabularies only model the "what" not the "how" transitions
  101. 101. VocabulariesI know what a Person is, but how can I interact with it?
  102. 102. VocabulariesI know what an hProduct is, but how can I interact with it?
  103. 103. VocabulariesI know what an ActivityStream is, but how can I interact with it?
  104. 104. The payoffWhere I make amends
  105. 105. The payoff state What if we combined the "what" of vocabularies
  106. 106. The payoff state What if we combined the "what" of vocabularies with the "how" of protocols? transitions
  107. 107. The payoff state What would that look like? transitions
  108. 108. The payoff XHTML Meta Data Profiles (XMDP) Tantek Celik, 2003
  109. 109. The payoff A few years on, a similar approach...
  110. 110. The payoff ALPS - Microblogging with XHTML Mike Amundsen, 2011
  111. 111. The payoff ALPS includes both state and transitions
  112. 112. The payoff ALPS(mb) hackathon at 2011 RESTFest. Initial experiment was a success. Independently built apps could interop.
  113. 113. The payoff Microblogging site rstatus implements ALPS(mb) in 2012
  114. 114. The payoff ALPS(mb) was a good idea but we can do better.
  115. 115. The payoff How about a profile spec that includes both state and transitions that works for a wide range of media types?
  116. 116. Application-Level Profile Semantics The sequel
  117. 117. ALPS Warning! What follows is early-stage, tentative design
  118. 118. ALPS Design and register two media types for describing problem domains. application/alps+xml (or +json)
  119. 119. ALPS
  120. 120. ALPS
  121. 121. ALPS
  122. 122. ALPS
  123. 123. ALPSFour possible descriptor types:1. semantic (data)2. safe (HTTP.GET)3. unsafe (HTTP.POST)4. idempotent (HTTP.PUT & HTTP.DELETE)
  124. 124. ALPS
  125. 125. ALPSALPS id properties become representationidentifiers● @class, @rel, @name (HTML)● @rel, @name (Cj, HAL)● @rel (Atom)
  126. 126. ALPSApply these semantics to a wide range of existing media types
  127. 127. ALPS
  128. 128. ALPS There will be a set of rules for applying ALPS semantics to each media type.
  129. 129. ALPS
  130. 130. ALPS By applying semantic descriptors consistently...
  131. 131. ALPS
  132. 132. ALPS selecting an implementation media type can be independent of the state and transition semantics.
  133. 133. ALPS
  134. 134. ALPS selecting a reference vocabulary can be independent of the protocol semantics
  135. 135. ALPS
  136. 136. ALPS ALPS spec will provide several markup elements
  137. 137. ALPS Now we have a way to share understanding
  138. 138. ALPS Now we have a way to share understanding about a problem domain
  139. 139. ALPS Now we have a way to share understanding about a problem domain Not a service document (WSDL)
  140. 140. ALPS Now we have a way to share understanding about a problem domain Not a discovery document (Google, @mnot)
  141. 141. ALPS Now we have a way to share understanding about a problem domain Not a hypermedia type (HAL, Cj, Siren, etc.)
  142. 142. ALPS Now we have a way to share understanding about a problem domain Not a vocabulary repository
  143. 143. ALPS Now we have a way to share understanding about a problem domain Not an object graph
  144. 144. ALPSThis could give us tools for lots of tasks...
  145. 145. ALPS Describing a domain profile
  146. 146. ALPS Analyzing domain profiles
  147. 147. ALPS Matching domain profiles to media types
  148. 148. ALPS contactsgift lists school pals schema.org/Person photos matchmaker ancestry tree Sharing selected state with multiple services
  149. 149. ALPS Documenting domain profiles
  150. 150. ALPS Driving server-side representation engines
  151. 151. ALPS Driving client-side processing engines
  152. 152. ALPSPossible benefits of ALPS Repositories:● Share your domain profiles● Search for profiles by topic● Match abstracts w/ favored vocabularies● Reflect aggregate profile use/reference data
  153. 153. Summary So, where are we headed now?
  154. 154. Summary Snowflakes still common programmableWeb, 2012
  155. 155. Summary How many data types here? programmableWeb, 2012
  156. 156. Summary How much shared understanding here? programmableWeb, 2012
  157. 157. Fielding & Taylor, 2002 "REST components communicate by transferring a representation of the data in a format matching one of an evolving set of standard data types..."
  158. 158. Summary standard data types includes both state and transition types
  159. 159. Summary shared understanding includes both state and transition types
  160. 160. Summary because the Web includes both state and transition types
  161. 161. http ftpsmtp protocols dns ws xmpp
  162. 162. html csvhal media types atomjson Cj
  163. 163. schema.org dublin core VoID vocabularies activity streamsmicroformats
  164. 164. vCardmicro-blogging domain profiles PersonhProduct accounting
  165. 165. Summary● ALPS IETF I-D will be posted in March● Watch my blog/twitter for details● Looking for feedback/contributions
  166. 166. Lets talk! RESTing in the ALPSGeneric Hypermedia and Domain-Specific APIs @mamund Mike Amundsen Principal API Architect, Layer 7 Technologies

×