So as he mentioned, I am Kirsten Hunter. 0:00 I've been working with REST APIs for almost ten years now. 0:02 I started working with them in 2005 and 0:06 I've learned a lot about how, how to make APIs that developers love. 0:09 I always say that I wander the world like Caine in Kung Fu 0:15 teaching companies how to make APIs that develop don't make developers cry and 0:19 teaching developers to use APIs without crying. 0:24 So you'll see that I sort of design, it was designing irresistible APIs. 0:28 I had a talk with my publisher yesterday. 0:31 I'm, I'm writing a book about this stuff. 0:33 And they're like well but you talk about design in it so 0:35 maybe creating,and then they're oh no, just go with irresistible APIs. 0:38 So, this is about irresistible APIs. 0:42 There won't be any code, but I will give you a lot of, it should be interesting for 0:45 developers all the way up to executives. 0:49 People who want to understand how to have a good strategy for your APIs so 0:51 that it's, they're compelling, engaging, and fun. 0:56 So that was the intro. 1:01 Presentation style it says I promise notes on slideshare it always says that but 1:03 this particular topic I have on my blog princesspolymath.com. 1:08 There is a blog post at the very top that is about this, and 1:13 there's a webcast that I did for Oscon. 1:16 There's a link to the slide show, 1:19 and then there's a blog post that sort of sums it up. 1:20 So, the fact that I have these slides with just a couple words on them is for 1:22 a very specific reason. 1:28 Which is that I like to interact with the audience and 1:29 I like to pay attention to you. 1:32 If I have slides with bullets on them, then I'll read them to you and 1:34 you'll read them to you. 1:37 Everybody falls asleep. 1:39 Story time. 1:40 So this is, this is designed to be a conversation and not a lecture. 1:40 So, if you guys have questions, shout them out. 1:48 Ask me. 1:51 I love listening to myself talk and 1:52 I will talk for 45 minutes if you guys want to listen to me. 1:53 But please ask me questions if you have them. 1:57 I've been doing this a really long time so I probably have 2:00 some perspective on whatever, whatever it is you're curious about. 2:02 So love your API. 2:08 This is, this is the main focus of what I'm talking about here. 2:09 You're gonna make your API a first class product. 2:14 A lot of people don't make their API a first class product. 2:16 They let it grow organically, and I'll talk about that in a second. 2:19 But, basically you need to treat it like a real product. 2:23 You need to plan it. 2:26 You need to design it. 2:27 You need to develop it. 2:28 Put the resources on it, and support your developers so 2:29 that they have a great experience. 2:33 Organically grown APIs. 2:35 This is my favorite sort of way to describe them. 2:37 They're like, you have your product which is a potato and 2:40 you leave it in the garage for 30 days, and then all of a sudden it has all these 2:42 little sprouts and they're ugly, and not related to each other. 2:46 And nobody likes them and 2:49 they're, and, and, and they don't really work out for anything. 2:50 That's what happens when you, people just sorta try to slap an APON, 2:54 API on an existing backend without having an overall strategy. 2:57 You end up with inconsistent interfaces, something that happens on your 3:02 product on the main website works totally differently in the API. 3:05 You have duplicate code, which is, is kinda stinky. 3:09 It it means that when you have a bug in one place, you have a bu, 3:14 you have a different bug in the other place. 3:17 You never wanna have duplicate code. 3:20 You'll notice that the duplicate code is not exactly the same. 3:21 That's how it works. 3:24 Do you have a question? 3:26 You just wave [INAUDIBLE]. 3:28 >> [INAUDIBLE]. [INAUDIBLE] 3:29 >> Resource contention. 3:32 One of these things that people seem to think when we have these 3:33 organically grown APIs is that we're gonna make a new feature on the main product. 3:37 And then in their spare time, 3:41 the developers are going to also make an API and it's gonna be great. 3:44 Well, developers already have to develop the code. 3:48 They have to do something with documentation, 3:50 which they don't really like. 3:52 They have to do stuff with tests, which a very few of them actually like. 3:53 And now you're saying you also have to make an API. 3:56 If you don't set aside actual resources for this, it's not gonna happen. 3:59 You're gonna end up with a serious mismatch. 4:04 And you're gonna end up with feature mismatch. 4:06 So this is the ugly pants API but you will see that they're not the same ugly pants, 4:09 they're different from each other. 4:15 What does make an API great? 4:18 How, how do you create an API that everybody talks about and loves? 4:21 And also I want to make a side point here. 4:26 Some of you are gonna have internal only APIs. 4:30 You're in an enterprise and your customers are internal. 4:32 And you're gonna argue to me no, actually, I don't have to care about my developers, 4:35 the developer experience is not important to me. 4:39 Let me just tell you is it more important to you if people have to use your API and 4:42 it hard to use, and it's not clear how you're suppose to use it. 4:46 You're end up with huge support cost and internal politics problems. 4:50 So you need to think of your developers as customers, what ever kind of API. 4:53 Whether it's open API's, which is mostly how I refer to these. 4:58 But even if it's internal, that's a really important thing to do. 5:01 So what makes an API great is basically a fantastic developer experience. 5:05 You want to make it so people want to use your API, that they enjoy using your API, 5:08 and they get, and they use it in a way that you expect them to. 5:13 And how do you do that? 5:16 With deliberate design. 5:19 Instead of having your organically grown potato. 5:20 You know, you, 5:23 you couldn't make origami if you didn't know what you were doing at the beginning. 5:24 Right? You would end up with, 5:28 well, a flapping bird or you know, a wingless swan or something. 5:29 It doesn't work. 5:35 And so we're gonna talk about the process of going through and 5:36 creating your API just like any other product. 5:39 And now I'm gonna digress again, cuz I do that, and talk about API first. 5:45 This is the Utopian ideal of the API world. 5:49 This is the world where instead of having your product run off of your back end and 5:53 your API run off of your back end separately. 5:57 You have your API run off of your back end and all of your products, 6:00 your mobile devices, your main website and everything, all runs off of that same API. 6:03 And when you open those up and let other people use them, they're the same API. 6:09 Now, we don't have code duplication. 6:13 We don't have feature mismatches. 6:16 Our interfaces are consistent. 6:17 And I have people telling me, no. 6:19 I can't do that cuz I'm a little start up and 6:21 we don't have time to put the framework in place. 6:23 It does improve your productivity and makes your iterations faster. 6:26 So, when you're starting out, it's still a great thing to think about, 6:31 especially if you're gonna have more than one product, and you probably are. 6:34 You're probably gonna have a web experience and 6:37 a mobile experience at least. 6:40 So, then I hear people saying oh no, we're, we're a really big company, and 6:43 we can't possibly refactor everything so that it, it's API first. 6:47 Like it's just not gonna happen. 6:52 So, I give you this picture is about Etsy. 6:53 Etsy is I think we can all agree that they're legit company. 6:58 They transacted over a billion dollars last year. 7:01 And they decided last year to go API first, and 7:05 they basically refactored their whole backend all at once. 7:08 And they discovered that an improved communication between their teams 7:12 it it made their iterations much faster. 7:17 It reduced the amount of bugs that they had. 7:19 It, it increase, increased their developer happiness because they, 7:21 they weren't having to do things in two different places, two different ways, or 7:25 come together. 7:29 And a few of the, the products that they have, a few of the features on their 7:31 website actually got significantly better, and were able to from asynchronous calls 7:35 that took several minutes, to synchronous calls that took less than a second. 7:39 So, I mean a part of that is because if you have a thing and you throw it away. 7:43 And then rebuild it after you've gone through and 7:47 figured out what your actual use case is. 7:50 It's gonna be better, but it is possible to do that. 7:52 Now, Akamai, the company that I work at is doing API first 7:56 in a slightly different way. 8:00 Again, we're a huge company and 8:01 we don't actually have the capability to refactor everything all at once. 8:03 So, we have a two year plan to try and 8:07 move everything, all of our products to an API backend. 8:09 Decouple everything and make it so that we can open up those APIs. 8:14 So, there's various ways to do this. 8:18 It's worth thinking about. 8:20 And even if you don't do it, at least you can think about what you're giving up. 8:22 What the cost is of not approaching things this way. 8:26 So the first thing you're gonna wanna think about in this planning of your, 8:31 of your API, creating an API that's irresistible is, why do you have an API? 8:35 So, imagine that you're stuck in an elevator with your CEO and 8:41 your CEO turns to you and says, why do we have an API. 8:44 Historically speaking the answer that developers like to give is because API. 8:48 Everyone should have one. 8:55 We should have one too. 8:56 And then your CEO takes all of your developers and 8:58 moves them over to a place that actually makes money, and you have no API. 9:00 So, you need a business, you need to know what the business value is of your API. 9:04 And even internal APIs, what are, what is it that you are trying to achieve? 9:09 So, I'll give you some ideas for 9:12 open things to give you an idea of how that works out. 9:14 Mobile or market penetration. 9:19 Let's all think about Netflix. 9:21 Okay. So, Netflix has an API. 9:23 It use to be open. 9:24 It's not so open any more, but they still use it for their devices. 9:25 And they had a strategy that basically went like this. 9:28 If there's a thing and 9:32 it makes pictures, and it makes video and it's connected to the internet. 9:33 It should have Netflix on it. 9:38 So, now you can't buy a Blu-ray player or any kind of smart TV or 9:40 anything that doesn't have Netflix on it. 9:43 We're starting to get more Hulu and Amazon Prime. 9:45 But Netflix is not a competitive advantage any more. 9:48 Not having Netflix is a competitive disadvantage. 9:53 No one's gonna buy your Blu-ray player if it doesn't have Netflix. 9:56 So, by having an API that was really easy to integrate with, 9:59 they made it a, an, aggressively going out and using that, 10:03 the simplicity of that integration to chase down the manufacturers. 10:07 They created this market penetration that, 10:12 that assures them of a certain amount of traffic well into the future. 10:15 Driving usage, Twitter's a great example. 10:21 So, when Twitter started they were, like this page, and 10:24 you could type in your 140 characters and you could follow people, and that was it. 10:27 If they hadn't had an API we wouldn't, we wouldn't use Twitter the way we do now. 10:31 We, we tweet from everywhere, we share things. 10:36 We integrate with a lot of other kinds of systems. 10:39 And as a result, the, the stream is much more rich. 10:43 People are able to integrate to integrate their applications with Twitter, and 10:47 so Twitter can have information coming in whether it's shared off of a news site or 10:52 whether you did something cool with your Fitbit. 10:56 Or whatever, whatever it is that you're gonna share. 11:00 So, the usage for Twitter, the thing that's really important for 11:03 Twitter is that people write to the stream. 11:06 If people don't write to the stream, its boring, and then people go away. 11:08 So, that's what they use their API for, it was to drive usage. 11:12 They did some not terribly popular things for the developer experience. 11:16 But in general, their API was successful in this goal. 11:21 Getting their first will help you to defend against interlopers. 11:28 Best Buy actually had one of the first API's in their, in their industry. 11:33 And it helped them to get a lot of traction and 11:38 integration with other people and other products. 11:41 So, Amazon was their first, and 11:45 they have consistently been their first for different kinds of features. 11:47 So the fact that their website is a little hard to use 11:51 doesn't mean that people don't buy things from them. 11:55 They are again the defacto standard. 11:57 And they are very committed to API's and making it possible for 11:59 people that integrate with them. 12:03 My favorite of all of the business values, and this is the one that your CEO 12:05 will really love, partners connectivity, partners stickiness. 12:10 So, if you have a partner and they've integrated with your API, and 12:14 they've updated your, integrated so that their reporting includes information from 12:18 your API as well as their back end systems. 12:23 And then six months from now, 12:26 somebody says, hey, we really wanna buy this other product. 12:28 The engineering manager's gonna push back, they're gonna say, I don't, 12:31 we wrote code, and it works. 12:35 So we don't wanna write more code. 12:36 So, it doesn't give you a free pass if you have a terrible developer experience or 12:38 bad support, people still might wander off. 12:42 But it does add some friction to that decision to make the change and 12:45 it gives you an opportunity to try to keep those partners. 12:48 Partner contracts are one of the most stable sources of income for 12:53 most companies. 12:57 And so being able to get your hooks in [LAUGH] is, is a really helpful way to get 12:57 people to play with your stuff and, and keep, keep using your main product. 13:02 And then there's a few technical cases, 13:08 making things that are super hard, super easy. 13:11 this, this is usually the case when you are talking about a company that, 13:16 where their API is their main product. 13:20 So, SendGrid and Twilio, and Contacts.io. 13:22 So these people SendGrid makes it easy to send in and, 13:27 and deal with email from the sending side. 13:31 Contacts.io makes it easy to deal with email on your side. 13:34 It can make it so that you can have really complicated rules, 13:37 you can actually use your email as almost kind of a database. 13:41 Dealing with emails pretty tough on a programmatic basis. 13:46 So it's really nice to have these APIs that will deal with this for you. 13:49 Tullio, so who of you have written telephony clients before? 13:54 [LAUGH] It's hard. 13:58 Sending us a messages doing voice conferences. 14:02 all, transcription, all of the things that Twilio does. 14:07 It's not magic because they have a great developer experience, although they do. 14:10 It's magic because these are things that you, you just wouldn't add SMS 14:15 integration into your application if there weren't an easy way to do it. 14:19 It's, it's not most people it's not their core competency, and 14:23 it is very, very difficult. 14:26 So now we've got our business value. 14:29 We know what it is that we want to do with our API. 14:31 How do we measure success? 14:33 So I've worked at companies where the metric that we use is how 14:36 many people have an API key? 14:40 Okay. 14:41 That's, that's probably not interesting at all to your CEO when you're standing in 14:43 the elevator,. 14:46 Something more interesting might be how many people are using the API 14:49 versus how many people are using the main product. 14:52 It's a lot cheaper for you if people use the API. 14:54 Your sending a lot less information across the stream, and 14:56 their doing sort of the client end. 15:00 Whoever the, that application is. 15:01 Maybe it's, you know, are your partners using it consistently? 15:05 Is that helping? 15:09 Whatever your business value is, 15:10 figure out how you want to measure it, what chart or graphs you're gonna show, 15:11 and also this will help you chase down what your use cases should be. 15:15 Use cases are critically important in 15:20 terms of figuring out how you're gonna design you API. 15:23 I'm gonna talk about some other architectural considerations. 15:25 But the use cases are gonna be in my opinion, 15:29 your main product should, should essentially be an API use case. 15:32 Mobile should be an API use case. 15:37 integration, if you want to have integration with social systems, 15:40 then maybe that should be a use case as well. 15:44 So, once you've fitted, figured out your business value and 15:47 how you're gonna measure it. 15:49 It should be a lot easier to come up with use cases. 15:50 How do you want people to use your API? 15:53 Which things should be easy? 15:55 So, architectural considerations. 15:56 I am going to talk a little bit about mobile as a, 16:02 as a target, to give you an example of what it is that you are thinking about. 16:05 So if you want people to use your API for 16:10 mobile devices then you have to realize some things. 16:12 First of all they don't like getting a lot of extra data. 16:16 They, they wanna get exactly the data that they want and they wanna get it fast. 16:20 Second of all, they want one copper screen. 16:24 So you need to be very careful when you make those mobile use cases that 16:27 you figure out a way to make it possible for 16:30 them to do one call per screen as opposed to making 50 calls. 16:32 Those of you the people who use phones they walk into into elevators, 16:36 they go under tunnels especially around here and, and the connectivity goes down. 16:41 So, you retry one call that's not so bad. 16:48 You recall 50 calls that's kind of a pain. 16:51 And also most phones don't thread too well and 16:53 you end up with a nonperformant application. 16:56 So people wander off and use somebody else's API. 16:58 One of the ways you can give somebody what they need, 17:03 exactly what they need is to have an expressive query language. 17:05 So, Netflix has a pretty basic expressive query langauge because their, 17:09 their content is, is a pretty simple graph. 17:14 There's movies and there's people and there's genres. 17:17 And other than that, there's not a lot of stuff. 17:21 So what they made it possible to do is, 17:23 as a device, you want to pull all the information about this movie. 17:26 But you'd also like to get some information about the cast, 17:30 and maybe pictures of the actors, and information about the director, so 17:32 that you can create a really excellent experience on your device. 17:36 So the, what Netflix allows you to do is just expand those queries. 17:40 So you can say I want this movie and expand the cast, 17:45 the director, and the genre information. 17:48 And then you know, 17:52 the device can use that information, it doesn't have to make a lot of calls. 17:54 In this case, the Buse case devices. 17:57 If they're going. 18:02 If you're going to be watching a streaming movie from Netflix you probably have 18:02 a pretty fat pipe. 18:06 So, it's not necessary to consolidate that down and make peep, 18:07 make it possible for people to get less information and very targeted information. 18:13 LinkedIn on the other hand has a very complicated graph. 18:21 There's people and they have connections and there's schools and there's 18:24 businesses and there's organizations and there's all of these different things. 18:28 And they want to make it possible especially for mobile devices, but 18:32 any device to be able to say I wanna know all my connections what, 18:35 what state their, their their school was in and 18:41 what company they worked for and how long they've worked there. 18:45 But I don't want other information, I just want those things. 18:48 So, Netflix, LinkedIn made it possible to express that kind of, 18:51 of level of, of specificity. 18:56 The problem is that that makes it more complicated for users. 19:00 But for the developers, it is a little bit harder of a developer experience. 19:03 But on the other hand, once they get exactly what they want, 19:07 they can continue to give exactly what they want. 19:10 And, and LIncoln kind of encourages people to do this. 19:14 The default object for most things is very, very simple. 19:18 So they want you to express exactly which fields that you want, and 19:23 which ones you want to be expanded out. 19:26 Another one of the architectural considerations you're gonna have 19:30 is hypermedia. 19:33 Do you have stuff that's, that's very closely linked to other stuff? 19:34 Netflix does in fact use hypermedia. 19:40 So, one of the ways you can figure out what you can expand in their API, 19:42 if your device is through the meta links that they have, 19:46 that show what the related items are. 19:51 So, there's a movie, and 19:53 one of the related items is the cast for that movie, for instance. 19:56 So, hypermedia is a fantastic thing. 20:00 One of the nice things about hypermedia is you, 20:02 this is one of the decisions that you can kinda put off until later. 20:05 If you add metadata to an existing API, it's not gonna break anybody. 20:08 So, when your people start, your developers start coming to you and 20:12 saying, I wanna be able to discover more information about the items that I 20:16 am looking at could you please make it easier for me to do that. 20:21 Then, hypermedia is a great idea. 20:24 But you don't have to have it right up front, it's just, 20:27 it's something that you should consider. 20:29 You should read a little bit about hypermedia, 20:31 figure out if it's something that will make your API more compelling for 20:34 users, if that's how you want to make it easier for people to do things. 20:37 One of the things that happened when we went from SOAP to REST is that a lot of 20:44 enterprise people got really upset, because they, they thought, 20:47 oh now everyone can see everything and we can't control it anymore. 20:50 That's not really true. 20:54 Just with any, 20:55 as with any other system you can control who sees what and who can do what. 20:56 I try to remind everybody that,that authentication is 21:02 different from authorization. 21:05 So I have a driver's license. 21:07 It says who I am. 21:10 That's my, that, that's, I have now authenticated it. 21:11 You know who I am. 21:13 But that doesn't necessarily mean I can vote. 21:15 It doesn't necessarily mean I can buy beer. 21:17 It doesn't necessarily mean I can be the president yet. 21:20 So keep in mind that sometimes you're gonna have user that have specific eh, 21:24 a specific read-only or very, very closed access. 21:30 And sometimes you can have administrators that can do pretty much any, 21:36 anything that they want to do. 21:40 So you've got your use cases, 21:44 you've got your business value, how you're gonna use it, you've got your use cases. 21:45 Now how are you gonna describe your API? 21:49 One of the big problems with API's is that the developers figure out how 21:51 they're gonna make the API but they don't have a really good way to describe this to 21:55 product managers or other people who might want to know how the API is going to work. 22:00 Schema modeling is an excellent way to describe how the API is gonna work. 22:06 Apiary has a, a, a, uses Blueprint. 22:11 Ulsoft has Ramel Reverb has swaggered their, 22:14 a bunch of different ways to, to represent this information. 22:18 But what's really important about it is it describes how your API is going to behave. 22:22 If you use someone like Apiary you can actually create a mock server. 22:28 People will be able to take their clients and throw it against that and 22:31 see if it's gonna have the, the depth of information they're looking for. 22:34 This is a valuable, valuable step that frequently gets skipped. 22:38 And this allows to ensure that consistency across your APIs. 22:42 I've seen cases where the user that shows up under account is totally different from 22:47 the user that shows up under ownership of pages. 22:51 You don't wanna do that to your developers. 22:54 You wanna make sure that a user is a user, is a user wherever they run into it. 22:57 And one of the things that will be helpful with that is if you model your schema, 23:01 you can look at it and 23:04 see where those inconsistencies are before you start developing. 23:05 And I'm sure you're all familiar with the, the notion of test-driven development that 23:11 we all rambled about for several years while we were doing Agile development. 23:15 So I'm advocating for design driven development. 23:21 So we're not making a test that fails and then writing code so that it succeeds. 23:23 I mean that's super fun, it's a great game, 23:27 and, and it, it's good until you are super busy. 23:28 Design driven development says what we're, 23:32 what we're coding against is that design that we've created. 23:36 We're making sure that that is true. 23:38 We're making sure that we're sending back exactly what we said we 23:40 were gonna send back. 23:44 It's whatever version of schema modeling you use. 23:46 It is a blueprint. 23:49 It describes how your API is gonna work. 23:51 And if you develop against it, you're gonna have a lot fewer iterations. 23:53 You're gonna have a lot fewer situations where developers are going to 23:56 have to re-do work. 24:00 Which is very frustrating. 24:01 And your iterations will be faster. 24:03 And you'll get to those used cases a lot faster if you know how it 24:05 is that you expect to get to them. 24:08 So I'm gonna give you guys a little story about, 24:13 about when I gave a workshop in Europe. 24:16 So I was in London at the Future of Web Apps. 24:19 A few weeks ago. 24:23 And I gave a workshop where I had people do a really complicated thing. 24:24 Which was, you know, create a mock API and then put it on the Google cloud and 24:30 look at it in Rumscope and, and de, deploy it to the cloud. 24:34 And then they all just sat there and looked at me. 24:38 And I was like, do you have a question? 24:42 Was it fun? 24:44 Is it excite, you know, and then, and finally, 24:45 one of them sort of looked at me and 24:47 said, I'm resting on my laurels because I just applied something to the cloud. 24:49 And I was like oh, that's your ecstatic phase. 24:55 So, I like Americans cuz Americans, they, they know they have the happy face. 24:59 They have the confused face, they have the bored face. 25:03 I can figure out whether I need to speed up, 25:06 slow down expand on something, slow things down. 25:08 But whatever it is that the ecstatic face looks like for your developer, so 25:11 this is an ecstatic London developer right here. 25:15 Whatever that ecstatic face is, 25:19 that's the face you want them to be making when they think about and use your API. 25:20 The first thing you wanna do is think about how to communicate with them. 25:26 Now you know your business value you have. 25:30 You're gonna measure it. 25:32 Your use cases, you have a design. 25:33 You're developing based on the design. 25:35 I would argue that you need to tell your developers all of those things. 25:38 Why? 25:41 Because many times in the past, people have not communicated what their 25:42 goals are for the API, and then the API's been pulled out from under the developers. 25:45 Developers are gun shy. 25:50 They might not want to use your API if they aren't sure it's 25:52 gonna be there in a year. 25:55 They're trying to monetize or they're trying to make a product. 25:55 And then need to under, believe that you have a solid foundation. 25:59 Is, if you show them, hey, I thought through this stuff. 26:03 I actually have a plan for this API, and this is how I'm gonna measure it. 26:05 They'll help you, they want your API to succeed. 26:10 So that if you say what I want is write to the, 26:12 to the stream, they'll think about how to do that. 26:15 How do I write to the stream? 26:17 So, treat your developers as valued partners, 26:19 not as annoying kids on your lawn. 26:23 I, I, I've found people who do both, and generally, 26:28 developers will react in exactly the way that you, you interact with them. 26:31 These people are giving you the most valuable thing they have, their time. 26:35 They're never gonna get any more of it. 26:39 So, if you show that you respect that, then they will trust you. 26:41 And they will start using your API. 26:46 Again, internal API's, still important for people to understand the goals of the API, 26:47 what you want them to do with it, how you want them to do that. 26:52 Marketing to developers is not like marketing to regular people. 26:57 This always gets re-tweeted as not like marketing to real people which, you know, 27:02 I can own that, but 27:07 really it's regular people like pictures of pretty things and developers like toys. 27:08 They like examples. 27:13 They want to know why do I care about your API? 27:16 What can I do with your API and how would I do that? 27:18 unfortunately, we are generally very good at documentation that 27:21 says what does this call do. 27:24 But if the person doesn't have the context and 27:25 understand why that's important to them, it's not really meaningful. 27:28 Twilio has a very strong belief that a developer who comes to their site 27:35 should be able to make a, an actual call against their API within five minutes. 27:40 Akamai, not so much. 27:45 We have very complicated authentication systems, so 27:47 we try to get people to make their first call in 20 minutes. 27:50 [LAUGH]. 27:53 But have a target. 27:53 Try to make it really easy for people to make that first call. 27:54 Make it clear to them that it is important to you that they engage with the API. 27:57 Once they've made that call, you kind of have your hooks in them. 28:01 They are kind of now invested in your API, 28:04 and they're gonna look around some more and see what else they can do. 28:08 Example Code: these are toys. 28:12 I actually have started making something I call "The Island of Broken Toys" where I 28:15 have a working, script and then I have one that's kind of broken in four or 28:19 five different ways so that people can debug and figure out how the system works. 28:23 Make it really fun for people to play with your example code. 28:29 It should be really easy for people to use things. 28:32 Encourage your community to add more examples. 28:35 The more ways that people can interact without actually starting from scratch, 28:39 the more likely it is they'll stick with you. 28:44 And give them tools, tools such as 28:49 console Apple G has a console IO Docs is what Mashery uses. 28:53 Make it possible for 28:57 people to explore your API without having to make those calls. 28:58 So if what they wanna do is go look around and 29:02 kind of see what the various things are. 29:04 This is especially useful for someone who has already made that first call and 29:06 now they're trying to figure out what it is that they wanna do and 29:09 what they wanna build. 29:12 Encourage them to use things like HTTP sniffers or 29:15 RunScope, to understand what that traffic looks like. 29:18 Help them to be successful. 29:21 Assume that they're gonna have a problem at three o'clock in morning cuz 29:23 they're hacking on your API and that's when they were awake. 29:26 And they, they get frustrated, and they come, and they ask a question. 29:29 Well, you're not there until you know, we're developers, so ten or 29:33 11 in the morning, and that's a long time for someone to wait who's frustrated. 29:37 So, try to get ahead of it, and teach them how to do what they 29:41 want to do with your API without needing your direct help. 29:46 But do you give him them that direct help when they need it? 29:50 Tell them what your SLA is. 29:53 Are you gonna respond to the requests on the forum tomorrow morning? 29:54 Are you gonna respond to emails in four hours? 29:59 It's what ever you choose is fine, but 30:04 you need to make sure that your developers understand what that, what that SLA is. 30:06 Understand what they can expect from you. 30:09 Otherwise they get frustrated. 30:12 They're already frustrated cuz they're asking questions. 30:13 So you wanna make it, 30:15 it clear to them what they can expect to happen when they ask for help. 30:17 Okay, so. 30:23 All intelligent discourse on the Internet ends as soon as someone p, 30:25 posts a picture of a cat. 30:28 So here's my picture of a cat. 30:29 And now I'm gonna, I'm gonna encourage you to ask questions. 30:31 If you don't ask questions, then I'm gonna ask myself questions and 30:34 we don't really want that. 30:37 So remember that I've been an API evangelist for ten years, so think about 30:40 any questions you may have around APIs, around creating them or designing them or 30:46 supporting people and or, you know, ask myself questions. 30:51 >> So as I like to do let's make sure that we give Kirsten a round of applause first. 30:57 [APPLAUSE] 31:02