How APIs Enable Innovation and Interaction on the Internet
•Télécharger en tant que KEY, PDF•
0 j'aime•541 vues
I owe a big debt of gratitude to ProgrammableWeb -- they are the API masters, and some of the data in this presentation comes from their site.
Recommandé
Recommandé
Contenu connexe
Tendances
En vedette
En vedette (11)
Similaire à How APIs Enable Innovation and Interaction on the Internet
Similaire à How APIs Enable Innovation and Interaction on the Internet (20)
Dernier
Dernier (20)
How APIs Enable Innovation and Interaction on the Internet
- 1. Internet For Robots The How and Why of APIs prepared by Cory Forsyth (@bantic) Aug 2011
- 2. Cory Forsyth @bantic
- 3. What is an API?
- 7. Application User Programming Interface
- 8. Application User Programming Interface
- 9. Machines Understand Structured Data
- 10. Machines Understand Structured Data
- 12. Why?
- 13. expand reach monetize data encourage innovation flickr credit @kaet44
- 14. I owe everything to my API
- 15. I owe everything to my API • 1,000,000 Registered Apps • 13 Billion API calls per day
- 16. Innovation
- 17. Innovation
- 19. 3,200 Websites Have APIs
- 20. 3,200 Websites Have APIs
- 22. Billionaires 13 B/day data from ProgrammableWeb
- 23. Billionaires 13 B/day 5 B/day 5 B/day data from ProgrammableWeb
- 24. Companies APIs
- 25. Companies APIs
- 30. Why Not Provide API? • difficult, costly to build well • commoditize your data • enable competition • expose your data
- 31. Who Should Offer API? • dynamic content • timely content • user-generated content • company as platform
- 32. Who Might Not Offer API? • proprietary data set • protected data set • prohibitive cost
- 34. • get further faster • leverage existing user bases • personalization
- 35. Why Not Use API? • Lock-in • At the mercy of that API -- it could go down or be deprecated • At the mercy of the API producer
- 36. Why Not Use API?
- 43. Miscellany • API vs SDK • Unofficial APIs • Screen scraping
- 44. First API?
- 45. First API?
- 46. questions? prepared by Cory Forsyth (@bantic) Aug 2011
Notes de l'éditeur
- \n
- \n
- To begin with, it’s an acronym, which is why it’s pronounced ay-pee-eye, not something that rhymes with happy.\nstands for application programming interface ->\n
- but that doesn’t really tell us all that much about what an API actually *is*, and that’s because it’s a term that was originally coined by computer engineers like this guy\n
- so \n
- So these are two types of interface. One is designed for users, that’s us, humans, and then the other...when you see those words, ‘application programming,’ you should think, “robot”. The application programming interface is designed to be easy to see and read by a machine.\n
- So, you might wonder what an interface designed for a machine would look like. The answer is, it’s just the data. We humans are visual and we make meaning out of what we see by relating the positions, shapes, and colors of what we see, and that’s why user interfaces came along and we don’t just all browse the web from the command line. But for a script that’s trying to relate data to other data, all that stuff is extraneous. So, to make it easy for robots (and computer programs, and the programmers who create those programs), an API outputs structured text that can be easily parsed by the program.\n\nThey have been around since about 2000, although we didn’t see more than a handful until about 2005.\n
- So, you might wonder what an interface designed for a machine would look like. The answer is, it’s just the data. We humans are visual and we make meaning out of what we see by relating the positions, shapes, and colors of what we see, and that’s why user interfaces came along and we don’t just all browse the web from the command line. But for a script that’s trying to relate data to other data, all that stuff is extraneous. So, to make it easy for robots (and computer programs, and the programmers who create those programs), an API outputs structured text that can be easily parsed by the program.\n\nThey have been around since about 2000, although we didn’t see more than a handful until about 2005.\n
- the other side of this is that by using an api, a script or other computer program can *programmatically* interact with the site that offers that api. So in addition to reading data from that site, it can actually make actions that affect that site. For example, you could use twitter’s api to post a message. The human equivalent is to log in to twitter.com, type a tweet into the message box, and push the ‘tweet’ button. The robot equivalent, going through the api, is to just send some data and commands to twitter’s api to make that action happen.\n
- so -- now we know *what* an API is...why do we want it? why does this matter? what’s the big deal?\n
- a web site is just one representation of data. many web sites have at least two representations of their data, two interfaces...one that is designed to be readable and understandable on a web page, and then another one that’s designed to show the same information -- the same text, or tweets, or blog posts, wikipedia articles or checkins -- that same information, on a mobile phone’s browser. That’s an example of the same data powering two different views, two different interfaces. \n\n(You might hear developers sometimes talking about separating presentation from content, and this is what they mean -- they’re pointing out that the ‘meat’ if you will of a web page is that data, and it’s the same however it’s displayed.) \n\nso at the core an API is a simple concept -- you’re filtering out all that extra markup, the colors, the shapes, the positions of items on the page -- and returning just the pure data that’s used to generate that page. But this concept has had a really profound change on the web. APIs are driving an entirely new iteration of the internet -- because before them, websites were like little islands, their users and data all self-contained, but by providing data through APIs, and using scripts to consume and re-use that data, we are gluing the web together in a way that just didn’t exist before at all.\n
- who here reads tweets or posts them via twitter.com?\ntwitter is a platform. it’s core value now is in its api. the website is literally its own api client.\n\nso one reason to have an API is to let third-party companies and developers build new tools on top of your data that you didn’t have the time or ability to do yourself. You make the core data underlying your website available, and folks out there will make the apps for it that fit the needs that they have. And you can focus on just providing a good backbone of interesting data that people want to see.\n
- another reason companies build apis. to tap innovative third parties.\n\n4sq and 7 years ago -- tells you what you were doing roughly a year ago today. This is something that the folks at foursquare weren’t going to build, ever...it’s most likely something they never thought of building. But because they make their data available through an api, it becomes possible for other people to build innovative, unusual things like this that the folks at 4sq never would have thought of.\n
- another reason companies build apis. to tap innovative third parties.\n\n4sq and 7 years ago -- tells you what you were doing roughly a year ago today. This is something that the folks at foursquare weren’t going to build, ever...it’s most likely something they never thought of building. But because they make their data available through an api, it becomes possible for other people to build innovative, unusual things like this that the folks at 4sq never would have thought of.\n
- here’s another interesting one...an interactive infographic created by the folks at the NYTimes that shows most popular movies by zipcode around new york city. it wouldn’t have been possible to make this without using the google maps api and the netflix api. and it’s certainly not something that either of those companies would have built on their own, but because they made their data available, it could be used in a new way by the NYT\n
- does this seem high or low to you?\n
- only 105 APIs at end of 2005\ntook > 3 years to get 1000\ntook 2 more years to get next 1000\ntook 9 months to get next 1000\n\n
- so we already mentioned that twitter has the most-used api. there are two others that get billions of requests daily...who knows what they are?\n
- some companies are taking the idea of offering an API a step further. they *are* their apis....they are literally nothing more than an API platform.\n\nin fact, this is what my company is trying to do, too. we create games that go on big screens, like a digital billboard or jumbotron, or just the TV in a bar, and you can play those games by using your phone like a controller, either through calling in or using one of our apps. We build some of these games ourselves, but we present ourselves as a platform and offer an API for developers to use to create games themselves, and that’s the primary goal of the company, to be the \n
- some companies are taking the idea of offering an API a step further. they *are* their apis....they are literally nothing more than an API platform.\n\nin fact, this is what my company is trying to do, too. we create games that go on big screens, like a digital billboard or jumbotron, or just the TV in a bar, and you can play those games by using your phone like a controller, either through calling in or using one of our apps. We build some of these games ourselves, but we present ourselves as a platform and offer an API for developers to use to create games themselves, and that’s the primary goal of the company, to be the \n
- literally buying innovation at pennies on the dollar...offering minor prizes.\nNYC actually used this, too. they ran a contest they called NYC Big Apps...170 data sets..30 different agencies... $20,000. 85 new apps...they’re saving millions of dollars doing it this way. donteat.at was a winner\nMTA had ads in the subway. they think the best way to do this is let the people who are motivated and skilled build the things on their own and just let them have access to the data and get out of their way.\n
- literally buying innovation at pennies on the dollar...offering minor prizes.\nNYC actually used this, too. they ran a contest they called NYC Big Apps...170 data sets..30 different agencies... $20,000. 85 new apps...they’re saving millions of dollars doing it this way. donteat.at was a winner\nMTA had ads in the subway. they think the best way to do this is let the people who are motivated and skilled build the things on their own and just let them have access to the data and get out of their way.\n
- literally buying innovation at pennies on the dollar...offering minor prizes.\nNYC actually used this, too. they ran a contest they called NYC Big Apps...170 data sets..30 different agencies... $20,000. 85 new apps...they’re saving millions of dollars doing it this way. donteat.at was a winner\nMTA had ads in the subway. they think the best way to do this is let the people who are motivated and skilled build the things on their own and just let them have access to the data and get out of their way.\n
- literally buying innovation at pennies on the dollar...offering minor prizes.\nNYC actually used this, too. they ran a contest they called NYC Big Apps...170 data sets..30 different agencies... $20,000. 85 new apps...they’re saving millions of dollars doing it this way. donteat.at was a winner\nMTA had ads in the subway. they think the best way to do this is let the people who are motivated and skilled build the things on their own and just let them have access to the data and get out of their way.\n
- literally buying innovation at pennies on the dollar...offering minor prizes.\nNYC actually used this, too. they ran a contest they called NYC Big Apps...170 data sets..30 different agencies... $20,000. 85 new apps...they’re saving millions of dollars doing it this way. donteat.at was a winner\nMTA had ads in the subway. they think the best way to do this is let the people who are motivated and skilled build the things on their own and just let them have access to the data and get out of their way.\n
- having seen all these great use cases that companies have capitalized on by releasing APIs -- what are some reasons NOT to provide an api?\nnumber of reasons making an api isn’t as simple as ju\nnot all companies need APIs. sometimes it doesn’t make sense. \n\nstealing all your data. you might be a company that owns a set of data and it’s your most valuable asset and it doesn’t change much or ever and if someone else got ahold of it then they could use it in such a way that they could compete with your site. an example would be a company that sells location data, such as the white pages -- their data is valuable to them and if they just gave it away to another company, that company could set up a new website that competes directly with them.\n
- What sort of companies are naturally good fits to release APIs?\n\ndynamic --\n\nweave themselves into the fabric of the web --\n
- having an API will be seen more and more as necessity\nmarketplace expectation\n\nproprietary -- yellow pages\nprotected -- newspaper articles\n\ncompetitive market pressures forcing even these companies to offer APIs or come up with evolved business models that are more open.\n
- So I’ve talked a lot about the proliferation of APIs and some of the benefits that companies get from making their data available. Now I’m going to talk about the flip side of that -- why would a company, or a developer want to build upon an API?\n
- lazy programmer -- don’t reinvent\n\nuser bases -- import friends from facebook, capitalize on the fact that so many people aready have facebook, or use twitter, or something like that.\n
- if you use an API, you make the company that controls that API into your benevolent benefactor. They are your supplier of an important resource -- data. If the data you get from their company -- say for example you’re building something that displays tweets -- if you are reliant on displaying those tweets, you are now reliant on twitter’s API as your tweets supplier, and if twitter goes down, or worse, decides to cut you off, or for whatever other reason your supplier of tweets dries up, you are stuck. \n\nThis is not purely a thought experiment, either. Twitter has a bit of a history of antagonizing its developers. Last year they decided to make official mobile and desktop apps, which put them into direct competition with some of the twitter clients that had already been built on their API. And when you are a company that is competing directly with your supplier...well, you’re in trouble. In this case twitter literally controls the fate of the other apps that have been built on its platform that it considers competitive with its mobile or desktop apps. It controls the API keys that those developers use to authenticate with twitter’s api, so it can, at any moment, simply revoke their API key which would leave that app completely out in the cold.\n\nSimilarly, google recently decided to deprecate their Google Translate API, which is used to translate text between languages...as of December it will no longer exist, so any apps that are reliant on it have about 4 months to figure out another translation provider.\n
- if you use an API, you make the company that controls that API into your benevolent benefactor. They are your supplier of an important resource -- data. If the data you get from their company -- say for example you’re building something that displays tweets -- if you are reliant on displaying those tweets, you are now reliant on twitter’s API as your tweets supplier, and if twitter goes down, or worse, decides to cut you off, or for whatever other reason your supplier of tweets dries up, you are stuck. \n\nThis is not purely a thought experiment, either. Twitter has a bit of a history of antagonizing its developers. Last year they decided to make official mobile and desktop apps, which put them into direct competition with some of the twitter clients that had already been built on their API. And when you are a company that is competing directly with your supplier...well, you’re in trouble. In this case twitter literally controls the fate of the other apps that have been built on its platform that it considers competitive with its mobile or desktop apps. It controls the API keys that those developers use to authenticate with twitter’s api, so it can, at any moment, simply revoke their API key which would leave that app completely out in the cold.\n\nSimilarly, google recently decided to deprecate their Google Translate API, which is used to translate text between languages...as of December it will no longer exist, so any apps that are reliant on it have about 4 months to figure out another translation provider.\n
- \n
- permissions -- APIs don’t simply give *all* data away...they restrict you from seeing anything except the data you are authorized to see, the same way the websites themselves, do.\nwhen facebook shows privacy request pop-ups like this, they are asking what data they are allowed to show of yours (and only yours) to the program that is using their API\n
- permissions -- APIs don’t simply give *all* data away...they restrict you from seeing anything except the data you are authorized to see, the same way the websites themselves, do.\nwhen facebook shows privacy request pop-ups like this, they are asking what data they are allowed to show of yours (and only yours) to the program that is using their API\n
- and the way they restrict access to certain features is using this, OAuth. It’s neat.\n\nold way -- you give your username and password -- this is bad for lots of reasons\n
- and the way they restrict access to certain features is using this, OAuth. It’s neat.\n\nold way -- you give your username and password -- this is bad for lots of reasons\n
- and the way they restrict access to certain features is using this, OAuth. It’s neat.\n\nold way -- you give your username and password -- this is bad for lots of reasons\n
- \n
- \n
- \n