Why would we be talking about APIs, CodePen doesn’t even have one, right? It’s true, we don’t have what is considered a traditional API. We explain why (and that we kinda do), and dig into the ins and outs of APIs on web apps.
- 1:39 What is an API for web software?
- 2:11 An API is just a way to get and send data: things like getting the past 10 photos (read), or post a new photo (write). An example of a popular API is Flickr’s.
- 2:51 Traditionally, read/writes are done over HTTP: you make a web request and stuff happens.
- 4:05 Certain things require special permissions: Facebook and oAuth are good examples of this.
5:41 In the context of CodePen, an API could be, “I want to get the last ten Pens from a user”. For most APIs, you’ll get the data back in the JSON format.
- 6:35 For most developers, creating an API means deciding what information you want to make available.
- 6:40 Think about APIs as a set of building blocks.
- 7:30 There’s a theory that you should build a web application with APIs first, and then use those APIs internally. It would be inefficient for us, for example, whenever we need to query data internally, to hit an external resource to get that data back into the application.
- 8:53 A lot of the external web requests we’re making to our application end up returning HTML instead of JSON, and because we’ve chosen to render HTML on the server and then serve that, it’s been more efficient and simpler for us to implement.
- 10:22 Why don’t we have an API? A big reason is that creating an API is a big time investment. There is a lot of engineering work that goes into making an API right, and we just haven’t got there yet.
- 11:22 Another reason is that we would have to support the API long term.
- 12:05 There’s a lot to think about when it comes to building and supporting APIs, and it’s not something you should take lightly.
- 13:02 What are the upsides to creating an API? It can be great for building your community. An API could be used by other developers to extend the use of your app to different platforms.
- 14:52 Why Dribbble decided to build an API, and what happened after they released it.
- 16:50 Growth, bandwidth, and the business challenges of supporting an API.
- 18:30 The other types of APIs: absolutely anything on the site could be an API, but what would be a good use of an CodePen API?
- 22:23 What happens when someone does something really cool with your API, and you want to use their idea for your app?
- 25:01 The costs associated with opening up an API: a third of CodePen’s monthly bill is bandwidth. Making an API could dramatically increase bandwidth costs.
- 27:35 Our “psuedo-APIs”: one example is that we made a way for users to copy a previous Pen into a new Pen. We also use RSS feeds, they aren’t exactly APIs, but they are similar.
- 28:30 What people want out of an API is a representation of a URL in different formats.
- 29:50 How the psuedo-APIs have become building blocks for bigger and better things.
- 30:25 We pay attention to specific use-cases instead of general ideas when considering when to open up access to data.
- 32:35 If we were to make a bunch of data available in JSON, what would we choose to open?
- 34:20 Using Keys to prevent API abuse by rate-limiting specific Keys: it would give us tools to keep our servers from getting stressed.
- 36:24 We’d love to make an API when we’re ready to support it properly, and we’d love to hear what your use-cases would be, because it would help us determine what we would make open.
Have any questions or thoughts? Feel free to drop them in the comments!