First-Class APIs, DPC 2011, Amsterdam

3,545 views

Published on

APIs are commonly an afterthought, like a hot tub awkwardly attached to a house — a shoehorned approach that produces a suboptimal app with scarce support that lacks documentation. In effect, APIs are the ugly stepchild of the Web.

This is a sad reality that we are faced with, because many companies make their living consuming third-party APIs and mixing in their own data to create amazing and interesting mashups. In the initial phases of development, there is rarely enough money to develop the app and its API. By the time there’s both demand and money, it can be hard to fit an API on top of the architecture in such a way that the whole thing won’t fall over. APIs should be first class citizens of the Web. Inconceivable? Possimpible? Not at all!

In this talk we will dive deeper into why APIs are an afterthought, how we can change that. We will also touch on how that can benefit your product down the line in terms of resource savings and infrastructure efficiency, as well as the impact it will have on your infrastructure.

This talk is inspired by my phpadvent article: http://phpadvent.org/201002

Published in: Technology, Business
1 Comment
6 Likes
Statistics
Notes
No Downloads
Views
Total views
3,545
On SlideShare
0
From Embeds
0
Number of Embeds
40
Actions
Shares
0
Downloads
44
Comments
1
Likes
6
Embeds 0
No embeds

No notes for slide

First-Class APIs, DPC 2011, Amsterdam

  1. 1. First-Class APIs Helgi Þormar Þorbjörnsson Dutch PHP Conference, Amsterdam, 21st May 2011Tuesday, 24 May 2011
  2. 2. Hi there, I’m HelgiTuesday, 24 May 2011
  3. 3. VP of Engineering at Orchestra.ioTuesday, 24 May 2011
  4. 4. VP of Engineering at Orchestra.io Developer at PEARTuesday, 24 May 2011
  5. 5. VP of Engineering at Orchestra.io Developer at PEAR From IcelandTuesday, 24 May 2011
  6. 6. VP of Engineering at Orchestra.io Developer at PEAR From Iceland @h on TwitterTuesday, 24 May 2011
  7. 7. 1995 2000 2005 2010 John Musser Founder, Programmable WebTuesday, 24 May 2011
  8. 8. Why do we need a website? 1995 2000 2005 2010 John Musser Founder, Programmable WebTuesday, 24 May 2011
  9. 9. Why do we need Of course we a website? have a website 1995 2000 2005 2010 John Musser Founder, Programmable WebTuesday, 24 May 2011
  10. 10. Why do we need Of course we Why do we need a website? have a website an API? 1995 2000 2005 2010 John Musser Founder, Programmable WebTuesday, 24 May 2011
  11. 11. Why do we need Of course we Why do we need Of course we a website? have a website an API? have an API 1995 2000 2005 2010 John Musser Founder, Programmable WebTuesday, 24 May 2011
  12. 12. Data is the new business modelTuesday, 24 May 2011
  13. 13. APIs are the business glueTuesday, 24 May 2011
  14. 14. Business without an API?Tuesday, 24 May 2011
  15. 15. Developers hunger to use your dataTuesday, 24 May 2011
  16. 16. Do not keep it all to your selfTuesday, 24 May 2011
  17. 17. The data wasn’t yours to begin with!Tuesday, 24 May 2011
  18. 18. Tuesday, 24 May 2011
  19. 19. Mine? Mine? Mine? Mine? Mine? Mine? Mine? Mine? Mine?Tuesday, 24 May 2011
  20. 20. Not everyone believes thisTuesday, 24 May 2011
  21. 21. They do like their ivory towersTuesday, 24 May 2011
  22. 22. For years APIs have been treated as...Tuesday, 24 May 2011
  23. 23. Second-Class CitizenTuesday, 24 May 2011
  24. 24. Why?Tuesday, 24 May 2011
  25. 25. It’s a conceptional problemTuesday, 24 May 2011
  26. 26. Companies believing they will lose business if they shareTuesday, 24 May 2011
  27. 27. Websites are considered the businessTuesday, 24 May 2011
  28. 28. Not the APITuesday, 24 May 2011
  29. 29. APIs are for the cool kidsTuesday, 24 May 2011
  30. 30. Or...Tuesday, 24 May 2011
  31. 31. Not enough moneyTuesday, 24 May 2011
  32. 32. Not enough timeTuesday, 24 May 2011
  33. 33. Not enough resourcesTuesday, 24 May 2011
  34. 34. Not enough foresightTuesday, 24 May 2011
  35. 35. Finally the time/money comesTuesday, 24 May 2011
  36. 36. Shoehorned onto the websiteTuesday, 24 May 2011
  37. 37. Hot tub awkwardly attached to a houseTuesday, 24 May 2011
  38. 38. Tuesday, 24 May 2011
  39. 39. Sparse DocumentationTuesday, 24 May 2011
  40. 40. Ill maintained codeTuesday, 24 May 2011
  41. 41. Lack of testingTuesday, 24 May 2011
  42. 42. Ticket response time is in the weeks not daysTuesday, 24 May 2011
  43. 43. It is a problem with managementTuesday, 24 May 2011
  44. 44. APIs should be...Tuesday, 24 May 2011
  45. 45. First-Class CitizensTuesday, 24 May 2011
  46. 46. Tuesday, 24 May 2011
  47. 47. Inconceivable?Tuesday, 24 May 2011
  48. 48. Absolutely not!Tuesday, 24 May 2011
  49. 49. 2010 MobileTuesday, 24 May 2011
  50. 50. 2011 TabletsTuesday, 24 May 2011
  51. 51. There are few companies that really get thisTuesday, 24 May 2011
  52. 52. Opening up the API when they release mobile clientsTuesday, 24 May 2011
  53. 53. New trend for startupsTuesday, 24 May 2011
  54. 54. Start with an API Not a website.Tuesday, 24 May 2011
  55. 55. Start with an API Not a website.Tuesday, 24 May 2011
  56. 56. Why do this?Tuesday, 24 May 2011
  57. 57. Mashups!Tuesday, 24 May 2011
  58. 58. Supply and DemandTuesday, 24 May 2011
  59. 59. There is a demand for APIsTuesday, 24 May 2011
  60. 60. Developers are the supplyTuesday, 24 May 2011
  61. 61. Going First-Class?Tuesday, 24 May 2011
  62. 62. Common architectureTuesday, 24 May 2011
  63. 63. Data MVC MVC API WebsiteTuesday, 24 May 2011
  64. 64. RE Data JE MVC CT MVC ED API WebsiteTuesday, 24 May 2011
  65. 65. Data MVC API WebsiteTuesday, 24 May 2011
  66. 66. RE Data JE CT MVC ED API WebsiteTuesday, 24 May 2011
  67. 67. Upgrading the API to First-ClassTuesday, 24 May 2011
  68. 68. Data API Mobile MVC 3rd Party WebsiteTuesday, 24 May 2011
  69. 69. Website as a clientTuesday, 24 May 2011
  70. 70. Data API Mobile MVC 3rd Party JavaScript WebsiteTuesday, 24 May 2011
  71. 71. FRAPI (getfrapi.com)Tuesday, 24 May 2011
  72. 72. Any downsides!?Tuesday, 24 May 2011
  73. 73. Of course!Tuesday, 24 May 2011
  74. 74. The gain?Tuesday, 24 May 2011
  75. 75. API becomes the core businessTuesday, 24 May 2011
  76. 76. Better DocumentationTuesday, 24 May 2011
  77. 77. More extensive testsTuesday, 24 May 2011
  78. 78. Better response time on bugsTuesday, 24 May 2011
  79. 79. ConsistencyTuesday, 24 May 2011
  80. 80. Higher upfront cost but lower in the long termTuesday, 24 May 2011
  81. 81. TwitterTuesday, 24 May 2011
  82. 82. Started in 2006Tuesday, 24 May 2011
  83. 83. Took off in 2007 at SXSWTuesday, 24 May 2011
  84. 84. 20k 60k tweets per dayTuesday, 24 May 2011
  85. 85. 200% GrowthTuesday, 24 May 2011
  86. 86. There was no APITuesday, 24 May 2011
  87. 87. Developers asked for itTuesday, 24 May 2011
  88. 88. And of course it got bolted onTuesday, 24 May 2011
  89. 89. API was half cooked and organically grewTuesday, 24 May 2011
  90. 90. They tried their best, but...Tuesday, 24 May 2011
  91. 91. Tuesday, 24 May 2011
  92. 92. #NewTwitter in Oct 2010Tuesday, 24 May 2011
  93. 93. Web client consuming it’s own API.Tuesday, 24 May 2011
  94. 94. More care was taken on the API sideTuesday, 24 May 2011
  95. 95. What if Facebook did the same?Tuesday, 24 May 2011
  96. 96. In conclusionTuesday, 24 May 2011
  97. 97. Treat the API as your core businessTuesday, 24 May 2011
  98. 98. Or at least plan it from the startTuesday, 24 May 2011
  99. 99. Tuesday, 24 May 2011
  100. 100. Clients URL Login Shorteners etc etc Image etc Analytics HostingTuesday, 24 May 2011
  101. 101. Outsource the innovation of UX to people who know how to!Tuesday, 24 May 2011
  102. 102. Tuesday, 24 May 2011
  103. 103. N O M OR ETuesday, 24 May 2011
  104. 104. Thanks for coming! @h helgi@orchestra.io Joind.in: http://joind.in/3241Tuesday, 24 May 2011

×