First-Class APIs, DPC 2011, Amsterdam
•
6 gefällt mir•1,736 views
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
Empfohlen
Weitere ähnliche Inhalte
Mehr von Helgi Þormar Þorbjörnsson
Mehr von Helgi Þormar Þorbjörnsson (18)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
First-Class APIs, DPC 2011, Amsterdam
- 1. First-Class APIs Helgi Þormar Þorbjörnsson Dutch PHP Conference, Amsterdam, 21st May 2011 Tuesday, 24 May 2011
- 2. Hi there, I’m Helgi Tuesday, 24 May 2011
- 3. VP of Engineering at Orchestra.io Tuesday, 24 May 2011
- 4. VP of Engineering at Orchestra.io Developer at PEAR Tuesday, 24 May 2011
- 5. VP of Engineering at Orchestra.io Developer at PEAR From Iceland Tuesday, 24 May 2011
- 6. VP of Engineering at Orchestra.io Developer at PEAR From Iceland @h on Twitter Tuesday, 24 May 2011
- 7. 1995 2000 2005 2010 John Musser Founder, Programmable Web Tuesday, 24 May 2011
- 8. Why do we need a website? 1995 2000 2005 2010 John Musser Founder, Programmable Web Tuesday, 24 May 2011
- 9. Why do we need Of course we a website? have a website 1995 2000 2005 2010 John Musser Founder, Programmable Web Tuesday, 24 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 Web Tuesday, 24 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 Web Tuesday, 24 May 2011
- 12. Data is the new business model Tuesday, 24 May 2011
- 13. APIs are the business glue Tuesday, 24 May 2011
- 14. Business without an API? Tuesday, 24 May 2011
- 15. Developers hunger to use your data Tuesday, 24 May 2011
- 16. Do not keep it all to your self Tuesday, 24 May 2011
- 17. The data wasn’t yours to begin with! Tuesday, 24 May 2011
- 18. Tuesday, 24 May 2011
- 19. Mine? Mine? Mine? Mine? Mine? Mine? Mine? Mine? Mine? Tuesday, 24 May 2011
- 20. Not everyone believes this Tuesday, 24 May 2011
- 21. They do like their ivory towers Tuesday, 24 May 2011
- 22. For years APIs have been treated as... Tuesday, 24 May 2011
- 23. Second-Class Citizen Tuesday, 24 May 2011
- 24. Why? Tuesday, 24 May 2011
- 25. It’s a conceptional problem Tuesday, 24 May 2011
- 26. Companies believing they will lose business if they share Tuesday, 24 May 2011
- 27. Websites are considered the business Tuesday, 24 May 2011
- 28. Not the API Tuesday, 24 May 2011
- 29. APIs are for the cool kids Tuesday, 24 May 2011
- 30. Or... Tuesday, 24 May 2011
- 31. Not enough money Tuesday, 24 May 2011
- 32. Not enough time Tuesday, 24 May 2011
- 33. Not enough resources Tuesday, 24 May 2011
- 34. Not enough foresight Tuesday, 24 May 2011
- 35. Finally the time/money comes Tuesday, 24 May 2011
- 36. Shoehorned onto the website Tuesday, 24 May 2011
- 37. Hot tub awkwardly attached to a house Tuesday, 24 May 2011
- 38. Tuesday, 24 May 2011
- 39. Sparse Documentation Tuesday, 24 May 2011
- 40. Ill maintained code Tuesday, 24 May 2011
- 41. Lack of testing Tuesday, 24 May 2011
- 42. Ticket response time is in the weeks not days Tuesday, 24 May 2011
- 43. It is a problem with management Tuesday, 24 May 2011
- 44. APIs should be... Tuesday, 24 May 2011
- 45. First-Class Citizens Tuesday, 24 May 2011
- 46. Tuesday, 24 May 2011
- 47. Inconceivable? Tuesday, 24 May 2011
- 48. Absolutely not! Tuesday, 24 May 2011
- 49. 2010 Mobile Tuesday, 24 May 2011
- 50. 2011 Tablets Tuesday, 24 May 2011
- 51. There are few companies that really get this Tuesday, 24 May 2011
- 52. Opening up the API when they release mobile clients Tuesday, 24 May 2011
- 53. New trend for startups Tuesday, 24 May 2011
- 54. Start with an API Not a website. Tuesday, 24 May 2011
- 55. Start with an API Not a website. Tuesday, 24 May 2011
- 56. Why do this? Tuesday, 24 May 2011
- 57. Mashups! Tuesday, 24 May 2011
- 58. Supply and Demand Tuesday, 24 May 2011
- 59. There is a demand for APIs Tuesday, 24 May 2011
- 60. Developers are the supply Tuesday, 24 May 2011
- 61. Going First-Class? Tuesday, 24 May 2011
- 62. Common architecture Tuesday, 24 May 2011
- 63. Data MVC MVC API Website Tuesday, 24 May 2011
- 64. RE Data JE MVC CT MVC ED API Website Tuesday, 24 May 2011
- 65. Data MVC API Website Tuesday, 24 May 2011
- 66. RE Data JE CT MVC ED API Website Tuesday, 24 May 2011
- 67. Upgrading the API to First-Class Tuesday, 24 May 2011
- 68. Data API Mobile MVC 3rd Party Website Tuesday, 24 May 2011
- 69. Website as a client Tuesday, 24 May 2011
- 70. Data API Mobile MVC 3rd Party JavaScript Website Tuesday, 24 May 2011
- 71. FRAPI (getfrapi.com) Tuesday, 24 May 2011
- 72. Any downsides!? Tuesday, 24 May 2011
- 73. Of course! Tuesday, 24 May 2011
- 74. The gain? Tuesday, 24 May 2011
- 75. API becomes the core business Tuesday, 24 May 2011
- 76. Better Documentation Tuesday, 24 May 2011
- 77. More extensive tests Tuesday, 24 May 2011
- 78. Better response time on bugs Tuesday, 24 May 2011
- 79. Consistency Tuesday, 24 May 2011
- 80. Higher upfront cost but lower in the long term Tuesday, 24 May 2011
- 81. Twitter Tuesday, 24 May 2011
- 82. Started in 2006 Tuesday, 24 May 2011
- 83. Took off in 2007 at SXSW Tuesday, 24 May 2011
- 84. 20k 60k tweets per day Tuesday, 24 May 2011
- 85. 200% Growth Tuesday, 24 May 2011
- 86. There was no API Tuesday, 24 May 2011
- 87. Developers asked for it Tuesday, 24 May 2011
- 88. And of course it got bolted on Tuesday, 24 May 2011
- 89. API was half cooked and organically grew Tuesday, 24 May 2011
- 90. They tried their best, but... Tuesday, 24 May 2011
- 91. Tuesday, 24 May 2011
- 92. #NewTwitter in Oct 2010 Tuesday, 24 May 2011
- 93. Web client consuming it’s own API. Tuesday, 24 May 2011
- 94. More care was taken on the API side Tuesday, 24 May 2011
- 95. What if Facebook did the same? Tuesday, 24 May 2011
- 96. In conclusion Tuesday, 24 May 2011
- 97. Treat the API as your core business Tuesday, 24 May 2011
- 98. Or at least plan it from the start Tuesday, 24 May 2011
- 99. Tuesday, 24 May 2011
- 100. Clients URL Login Shorteners etc etc Image etc Analytics Hosting Tuesday, 24 May 2011
- 101. Outsource the innovation of UX to people who know how to! Tuesday, 24 May 2011
- 102. Tuesday, 24 May 2011
- 103. N O M OR E Tuesday, 24 May 2011
- 104. Thanks for coming! @h helgi@orchestra.io Joind.in: http://joind.in/3241 Tuesday, 24 May 2011