First-Class APIs, PHPTek 11, Chicago

  • 2,640 views
Uploaded 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 …

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,640
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
39
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. First-Class APIs Helgi Þormar Þorbjörnsson PHP Tek, Chicago, 25th May 2011Thursday, 26 May 2011
  • 2. Hi there, I’m HelgiThursday, 26 May 2011
  • 3. VP of Engineering at Orchestra.ioThursday, 26 May 2011
  • 4. VP of Engineering at Orchestra.io Developer at PEARThursday, 26 May 2011
  • 5. VP of Engineering at Orchestra.io Developer at PEAR From IcelandThursday, 26 May 2011
  • 6. VP of Engineering at Orchestra.io Developer at PEAR From Iceland @h on TwitterThursday, 26 May 2011
  • 7. 1995 2000 2005 2010 John Musser Founder, Programmable WebThursday, 26 May 2011
  • 8. Why do we need a website? 1995 2000 2005 2010 John Musser Founder, Programmable WebThursday, 26 May 2011
  • 9. Why do we need Of course we a website? have a website 1995 2000 2005 2010 John Musser Founder, Programmable WebThursday, 26 May 2011
  • 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 WebThursday, 26 May 2011
  • 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 WebThursday, 26 May 2011
  • 12. Data is the new business modelThursday, 26 May 2011
  • 13. APIs are the business glueThursday, 26 May 2011
  • 14. Business without an API?Thursday, 26 May 2011
  • 15. Developers hunger to use your dataThursday, 26 May 2011
  • 16. Do not keep it all to your selfThursday, 26 May 2011
  • 17. The data wasn’t yours to begin with!Thursday, 26 May 2011
  • 18. Thursday, 26 May 2011
  • 19. Mine? Mine? Mine? Mine? Mine? Mine? Mine? Mine? Mine?Thursday, 26 May 2011
  • 20. Not everyone believes thisThursday, 26 May 2011
  • 21. They do like their ivory towersThursday, 26 May 2011
  • 22. For years APIs have been treated as...Thursday, 26 May 2011
  • 23. Second-Class CitizenThursday, 26 May 2011
  • 24. Why?Thursday, 26 May 2011
  • 25. It’s a conceptional problemThursday, 26 May 2011
  • 26. Companies believe they will lose business if they shareThursday, 26 May 2011
  • 27. Websites are considered the businessThursday, 26 May 2011
  • 28. Not the APIThursday, 26 May 2011
  • 29. APIs are for the cool kidsThursday, 26 May 2011
  • 30. Or...Thursday, 26 May 2011
  • 31. Not enough moneyThursday, 26 May 2011
  • 32. Not enough timeThursday, 26 May 2011
  • 33. Not enough resourcesThursday, 26 May 2011
  • 34. Not enough foresightThursday, 26 May 2011
  • 35. Finally the time/money comesThursday, 26 May 2011
  • 36. Shoehorned onto the websiteThursday, 26 May 2011
  • 37. Hot tub awkwardly attached to a houseThursday, 26 May 2011
  • 38. Thursday, 26 May 2011
  • 39. Sparse DocumentationThursday, 26 May 2011
  • 40. Ill maintained codeThursday, 26 May 2011
  • 41. Lack of testingThursday, 26 May 2011
  • 42. Ticket response time is in the weeks not daysThursday, 26 May 2011
  • 43. It is a problem with managementThursday, 26 May 2011
  • 44. APIs should be...Thursday, 26 May 2011
  • 45. First-Class CitizensThursday, 26 May 2011
  • 46. Thursday, 26 May 2011
  • 47. Inconceivable?Thursday, 26 May 2011
  • 48. Absolutely not!Thursday, 26 May 2011
  • 49. 2010 MobileThursday, 26 May 2011
  • 50. 2011 TabletsThursday, 26 May 2011
  • 51. There are few companies that really get thisThursday, 26 May 2011
  • 52. Opening up the API when they release mobile clientsThursday, 26 May 2011
  • 53. New trend for startupsThursday, 26 May 2011
  • 54. Start with an API Not a website.Thursday, 26 May 2011
  • 55. Start with an API Not a website.Thursday, 26 May 2011
  • 56. Why do this?Thursday, 26 May 2011
  • 57. Mashups!Thursday, 26 May 2011
  • 58. Supply and DemandThursday, 26 May 2011
  • 59. There is a demand for APIsThursday, 26 May 2011
  • 60. Developers are the supplyThursday, 26 May 2011
  • 61. Going First-Class?Thursday, 26 May 2011
  • 62. Common architectureThursday, 26 May 2011
  • 63. DataThursday, 26 May 2011
  • 64. Data WebsiteThursday, 26 May 2011
  • 65. Data MVC WebsiteThursday, 26 May 2011
  • 66. Data MVC API WebsiteThursday, 26 May 2011
  • 67. Data MVC MVC API WebsiteThursday, 26 May 2011
  • 68. RE Data JE MVC CT MVC ED API WebsiteThursday, 26 May 2011
  • 69. DataThursday, 26 May 2011
  • 70. Data WebsiteThursday, 26 May 2011
  • 71. Data API WebsiteThursday, 26 May 2011
  • 72. Data MVC API WebsiteThursday, 26 May 2011
  • 73. RE Data JE CT MVC ED API WebsiteThursday, 26 May 2011
  • 74. Upgrading the API to First-ClassThursday, 26 May 2011
  • 75. DataThursday, 26 May 2011
  • 76. Data APIThursday, 26 May 2011
  • 77. Data API MVC WebsiteThursday, 26 May 2011
  • 78. Data API Mobile MVC WebsiteThursday, 26 May 2011
  • 79. Data API Mobile MVC 3rd Party WebsiteThursday, 26 May 2011
  • 80. Website as a clientThursday, 26 May 2011
  • 81. Data API Mobile MVC 3rd Party WebsiteThursday, 26 May 2011
  • 82. Data API Mobile MVC 3rd Party WebsiteThursday, 26 May 2011
  • 83. Data API Mobile MVC 3rd Party JavaScript WebsiteThursday, 26 May 2011
  • 84. FRAPI (getfrapi.com)Thursday, 26 May 2011
  • 85. API First?Thursday, 26 May 2011
  • 86. Ideally!Thursday, 26 May 2011
  • 87. At least plan for itThursday, 26 May 2011
  • 88. Higher upfront cost but lower in the long termThursday, 26 May 2011
  • 89. Any downsides!?Thursday, 26 May 2011
  • 90. Of course!Thursday, 26 May 2011
  • 91. Additional OverheadThursday, 26 May 2011
  • 92. OAuth/Security + WebsiteThursday, 26 May 2011
  • 93. Eventually ConsistentThursday, 26 May 2011
  • 94. The First version always sucksThursday, 26 May 2011
  • 95. Keep things internal if need beThursday, 26 May 2011
  • 96. Data API MVC WebsiteThursday, 26 May 2011
  • 97. Data API MVC WebsiteThursday, 26 May 2011
  • 98. Data API MVC Internal WebsiteThursday, 26 May 2011
  • 99. The gain?Thursday, 26 May 2011
  • 100. API becomes the core businessThursday, 26 May 2011
  • 101. Single CodebaseThursday, 26 May 2011
  • 102. Better DocumentationThursday, 26 May 2011
  • 103. More extensive testsThursday, 26 May 2011
  • 104. Better response time on bugsThursday, 26 May 2011
  • 105. ConsistencyThursday, 26 May 2011
  • 106. Higher upfront cost but lower in the long termThursday, 26 May 2011
  • 107. The Story of TwitterThursday, 26 May 2011
  • 108. This is just an exampleThursday, 26 May 2011
  • 109. I am not trying to be an asshole to Twitter :-)Thursday, 26 May 2011
  • 110. Started in 2006Thursday, 26 May 2011
  • 111. Took off in 2007 at SXSWThursday, 26 May 2011
  • 112. 20k 60k tweets per dayThursday, 26 May 2011
  • 113. 200% GrowthThursday, 26 May 2011
  • 114. There was no APIThursday, 26 May 2011
  • 115. Developers asked for itThursday, 26 May 2011
  • 116. And of course it got bolted onThursday, 26 May 2011
  • 117. API was half cooked and organically grewThursday, 26 May 2011
  • 118. They tried their best, but...Thursday, 26 May 2011
  • 119. Thursday, 26 May 2011
  • 120. #NewTwitter in Oct 2010Thursday, 26 May 2011
  • 121. Web client consuming it’s own API.Thursday, 26 May 2011
  • 122. More care was taken on the API sideThursday, 26 May 2011
  • 123. What if Facebook did the same?Thursday, 26 May 2011
  • 124. In conclusionThursday, 26 May 2011
  • 125. Treat the API as your core businessThursday, 26 May 2011
  • 126. Or at least plan it from the startThursday, 26 May 2011
  • 127. Thursday, 26 May 2011
  • 128. Clients URL Login Shorteners etc etc Image etc Analytics HostingThursday, 26 May 2011
  • 129. ApiGee & MasheryThursday, 26 May 2011
  • 130. Outsource the innovation of UX to people who know how to!Thursday, 26 May 2011
  • 131. Thursday, 26 May 2011
  • 132. N O M OR EThursday, 26 May 2011
  • 133. Thanks for coming! @h helgi@orchestra.io Joind.in: http://joind.in/3400Thursday, 26 May 2011