00:00:16.880
hey everyone my name is john we're going to talk about api design today uh how an awesome api can attract friends
00:00:22.640
make you rich and change the world uh real quick background um i am with a
00:00:28.960
startup called zencoder we do video and audio transcoding in the cloud so we're basically an api to high performance video and audio
00:00:35.120
transcoding so that's part of why i'm interested in apis for this talk
00:00:42.000
i hope you're interested in apis too i gave this talk at a single track conference once and uh uh this topic might be kind of dry for
00:00:47.120
some people but i think it's actually really really exciting and uh you're a self-selecting audience so hopefully you do too
00:00:52.640
um i'm only gonna spend a couple minutes on the basics of apis what an api is what basic terminology is
00:00:59.199
and then i want to get into what i think is more interesting which is how to make an api good and what what do apis actually enable uh in the
00:01:05.600
world that you can't do without them um so i'm going to uh try to keep this first part to about two
00:01:11.680
minutes i'm actually actually gonna time myself and only try to bore you for two minutes uh before moving on to what is maybe
00:01:17.360
more interesting so uh so the basics uh here um
00:01:23.040
an api is an application programming interface it's an interface between two bits of
00:01:28.560
code two applications uh it's kind of like a user interface
00:01:33.759
interestingly they're both interfaces only one is an interface to people for people and one is an interface for programs
00:01:40.640
um sometimes an api is uh uh sometimes something like a library or an
00:01:45.680
sdk is considered to be an api it's basically uh uh api between one
00:01:50.960
bit of functionality and the code that you write so it's within one you know memory space within one bit of code so you might have an api to ssh
00:01:57.680
functionality through net ssh but what i'm going to talk about today is a different kind of api and that is
00:02:03.360
things like web services these are interfaces between two separate applications over some level of of
00:02:09.840
distance um web services have been around for a little while early on there was
00:02:15.360
soap the ironically named simple object access protocol soap is not really uh
00:02:23.120
so probably still exists in the enterprise but even in the enterprise more and more people are moving to rest which is a much simpler way to to
00:02:30.239
structure an api rest is basically the realization that http is an api protocol it's an api
00:02:36.800
language the web itself is an api between a browser and a web server two bits of software
00:02:42.959
talking to each other via an api and this api called http rest can be
00:02:48.239
used for our own web services so with something like this you can
00:02:54.160
read information get records you can write information you can post records uh last thing when you are sending
00:03:00.560
information via web services you need a structure for that data so two common
00:03:05.599
ones are xml and uh json and that was one minute and 50 seconds so uh
00:03:11.040
uh done with the basics any any questions on the basics of apis that's that's pretty simple for this
00:03:16.159
audience i assume so uh uh i mentioned earlier that uh uh
00:03:22.159
why i'm interested in api is that that's what my company does we are a company where really all we do all
00:03:27.840
we have is an api um you don't use our service for anything other than uh
00:03:33.280
the api we have a web interface uh but the web interface is not really that interesting uh you don't sign up for um uh uh
00:03:40.959
for our our service to get access to this this is just a management console on top of what we do what we do is
00:03:47.200
fundamentally an api so uh um
00:03:54.000
a little bit of history here um this is actually a really bad history of web services there are things that
00:03:59.439
come before this but i think there's sort of an interesting progression in the growth of web services over the last few years um
00:04:07.599
uh remember uh flickr back in sort of the when people talked about web 2.0 um there were services like flickr and
00:04:14.080
twitter who had an api it was sort of a secondary side effect of what they did it wasn't the core of what they did
00:04:19.759
um but some people think that flickr succeeded because it had an api it wasn't
00:04:24.960
primarily an api but that actually enabled it to be the success that it was um
00:04:31.280
the the sort of second stage of this history is infrastructure as an api and this is where things get really
00:04:36.560
interesting so amazon web services is a platform that gives you an api
00:04:42.400
to like uh to linux uh it gives you an api to gigabytes that's pretty interesting
00:04:51.360
um the third stage in this history is uh technologies or maybe applications uh as
00:04:57.440
apis so twilio is an api to telephony um simple geo is an api to uh uh
00:05:05.039
geo location and there's a lot of companies doing this right now taking things that previously were done in
00:05:10.560
other ways and turning them into um api driven services
00:05:16.960
uh the the last the last stage in this this history is uh uh i didn't know what to call it so i
00:05:22.160
call it science fiction as an api um there are things coming up that are uh uh
00:05:27.840
really interesting when you think about them so has anyone ever used pi cloud what is pi cloud an api to you
00:05:35.520
snapchat a python that's kind of interesting uh how about crowdflower and mechanical turk what are those apis to you people
00:05:43.440
so hence science fiction you can now be driven by an api if you choose to
00:05:48.960
which is kind of interesting so uh um
00:05:55.680
if you if uh so so following this progression more and more apis are coming online apis are doing more and more interesting things
00:06:01.919
so how do you actually make an api that is good um uh i i don't want to make this a talk
00:06:08.720
about my company um so i'm going to uh blank out new names here uh but but but uh uh we actually get tweets
00:06:15.360
periodically um things like this seriously redacted is how all apis should be built or hacking up integration with redacted
00:06:22.240
and recurly i really love good apis they make my life as a developer suck so much less
00:06:28.080
does anyone resonate with that sentiment bad apis are like the most miserable
00:06:33.360
thing to work with as a developer can't get much more painful than a bad
00:06:39.280
api so what does it take to make a good api um and really how do you turn your api actually into a competitive
00:06:46.560
advantage a good api is not just something to have it's actually something that can uh
00:06:52.479
really help out your application so how do you design a good api i have about a dozen things i want to go
00:06:58.080
over and i want to talk through this too i i i'm this is not a comprehensive list
00:07:05.680
but here's some of my ideas and my experience with apis
00:07:10.880
uh so first use rest conventions this is this is pretty non-controversial
00:07:16.639
i imagine um rest is simple and rest is really commonly used if you're building an api
00:07:21.919
you're probably people using your api probably are going to work with you know 15 20 30 different apis over
00:07:27.840
the course of a few years and the more conventional you can make it the better the less people have to learn rest is simple
00:07:35.120
i'm not even going to go over this so second make use of http codes
00:07:42.960
http has a lot more response codes than just uh 200 404 here's some of the ones that we
00:07:49.599
use um and these actually give you a little bit more meeting meaning than just 200 or 404 or 500
00:07:57.199
so created accepted uh um there's some interesting ones like unauthorized payment required
00:08:03.120
uh conflict i'm a teapot which we actually don't use but it's on the spec which is interesting um and there's lots more
00:08:10.720
um so kind of pick maybe the subset that fit with your uh the problem that you're solving
00:08:18.560
um third uh any any any thoughts on response codes anyone seen an interesting use of
00:08:23.840
response codes or them used well or poorly
00:08:36.159
so third version your api um and this is something that should be
00:08:41.599
one of the first things you do with an api because it's much harder to add versioning after the fact than it is to bake it in from the
00:08:47.200
beginning um the reason to version an api is really really simple let's say this
00:08:53.040
is your api today um you get a record you get back a color and a velocity uh what if you decide that you want to
00:09:00.080
go beyond colors as as simple words like that you
00:09:06.560
want to go to hex values for colors and you just built an application expecting to get green back instead of
00:09:12.080
this hex value your application is all of a sudden going to break
00:09:18.399
so what do you do you can add versioning as a way of name spacing let's say a resource
00:09:25.839
you go from the v1 api to v2 api and people can choose which one they want
00:09:31.120
um there's a few ways to do this here's three different ways to kind of signal versioning in an api
00:09:36.959
um who who's dealt with this problem before and what did you decide to do
00:09:56.880
sure sure so using urls is pretty easy within rails routing yeah what are other considerations
00:10:16.839
uh
00:10:23.440
so there's actually a good a good point there which is uh whenever possible don't require a version change uh it's
00:10:29.040
it's a pain to keep multiple versions in sync you can with with a lot of things that look like
00:10:35.279
you might have to change an api structure you can oftentimes find a way to avoid uh making a breaking change or backwards and
00:10:41.040
compatible change but still you need the you need to reserve the ability to do that
00:10:46.160
occasionally if you absolutely need to any other considerations for this kind of thing
00:10:56.880
sure yeah caching can be much easier with the second method there
00:11:04.160
any rest purists here what do you think
00:11:17.519
however i think the middle one as long as you're using hypermedia properly the second one is the most minor of sins and
00:11:23.839
only the most academic people would be like really upset about it but ideally it
00:11:28.880
should not reverse at all
00:11:35.760
uh yes that would be why again it's like the most minor effect of whatever
00:11:45.760
would you be happier uh no but we should not derail this talk you know
00:11:52.880
if it could be later one more
00:12:10.560
so which one do you prefer accepted yeah so you can find plenty of
00:12:16.560
discussions on this topic online uh keep going
00:12:31.680
sure sure yeah you you the people there are debates online but at the end of the day you get to kind of the same place
00:12:38.240
i'd say the other consideration is aesthetic which one which one maybe looks better is easier to understand
00:12:45.600
but they'll work next smart validations
00:12:52.480
um so if if someone is uh let's say sending a request like this
00:12:57.519
they're posting a record your system uh and they provide a valid an api key of not a real key
00:13:03.040
so assume for a second that's not a real key what do you do
00:13:08.160
well you can do this you can do a 500 internal server error um uh you know there's a bad key so you
00:13:13.920
failed right but that's not a very good response this is a little better 401 unauthorized but you can do better
00:13:21.600
than this too what about this actually provide maybe an errors array back errors api key not found okay so now
00:13:28.480
people can really hone in on what's going on taking this a step further uh this errors array
00:13:34.160
is k is basically the same thing that we use when we build forms in rails right we have an array that maybe validates uh tells you
00:13:41.279
ideally tells you exactly what's wrong with the field there's no reason you can't do that with an api request validation either
00:13:48.880
but even here i think i think this could be improved too why not say api key not found please log
00:13:55.120
in to example.com account api to retrieve your api key so tell them what's wrong why it's wrong
00:14:01.680
and how to fix it given the complexity of working with apis the developer who finds this is
00:14:07.120
really going to appreciate that you took the extra time to add that little that little help help text there
00:14:14.000
anoth another example uh what's wrong with this request
00:14:21.680
yeah so so uh there's no comma in the json there who who's who spent like more than like minutes uh trying to troubleshoot
00:14:27.839
something like this in the past troubleshoot something like this in the past uh malform json
00:14:33.839
so you could return a 400 bad request this is a bad request uh but why not do this why not embed
00:14:39.440
like a simple json parser in your api so if they send in bad json or bad xml you can actually
00:14:44.800
tell them structurally here's what's wrong it's not that hard to do
00:14:52.720
any thoughts on validations well you may you may address this soon
00:14:58.560
but i've just seen situations where people have used http response
00:15:03.760
codes um that makes sense such as a redirect uh in certain instances for their api
00:15:10.320
rather than returning
00:15:16.240
yeah i mean i can't think of a specific situation right now but where they've used http response
00:15:22.720
codes that seem to have a fairly decent analogous meaning to what their api is doing
00:15:30.399
so maybe they'll use redirect a redirect response code instead of a 500 error in
00:15:35.440
certain cases yeah i think i think you absolutely should so so for this one maybe 400 is
00:15:40.560
the right one uh for a malform request you can get into trouble if you use something that's totally if it makes semantic sense but
00:15:47.040
it's totally breaks convention but but generally yeah i think i think you absolutely should a question for the
00:15:52.240
rest purists if that key was not found is that a 500 type error or like a 404 not found
00:15:58.880
what's not found uri for the resource so i mean this was a post right so the
00:16:05.360
correct answer would be to do what he did because it's a malformed request it's not like an error on the server
00:16:11.279
side so i'm sorry i'm just going back to the previous example of a bad key with correctly formed requests i'm
00:16:16.880
sorry if there's a if there's a bad key so if the key doesn't exist then i would
00:16:23.279
probably end up returning uh the same thing with the 403 and saying it's a bad request
00:16:28.800
but you know thank you um
00:16:36.560
so uh next uh uh api suggestion um strongly consider
00:16:43.680
using both json and xml um and there's a simple reason for this uh this guy here probably doesn't know
00:16:50.880
what json is or maybe thinks it would be a security security vulnerability um whereas this guy won't use xml on
00:16:57.519
principle we actually initially designed our api
00:17:03.839
only around json and we realized that net developers don't know how to use json like json is not built into
00:17:09.520
net and json and.net developers don't like to use third-party plugins i i think
00:17:14.799
correct me if i'm wrong here um so so we had to add xml to to make them happy um the good news is
00:17:22.319
that it's really easy to do this uh rails for example if you set your headers properly uh will automatically
00:17:29.520
parse json uh um uh and and and similarly uh this is all rails two
00:17:35.520
three i apologize about that uh but similarly it's really easy to return either json or xml
00:17:40.960
um on both sides of an api request without a lot of work you can support both
00:17:50.000
um here's an api design question for for you all uh
00:17:55.200
uh so the the hardest thing that we found here is uh json has
00:18:00.880
arrays as a simple uh native type whereas xml doesn't exactly um any thoughts on the
00:18:08.559
right xml to represent like an array i think rails.2xml uh
00:18:14.160
gives you like uh a node plural and then singular nodes underneath with a type of array
00:18:36.799
any other gotchas converting between xml and json that anyone's had trouble with so i mean if you look
00:18:43.120
at yourself the json it's much easier to add xml as a type if you're limiting yourself to a structure that can be represented in
00:18:48.559
json yeah a lot more flexibility it can always be converted sure so if you start with xml
00:18:53.840
you make to make decisions that are not compatible with simple.json yeah absolutely
00:19:03.200
um next document your api no one likes to write
00:19:09.520
documentation but apis absolutely need documentation um uh if anyone's ever tried to work with an
00:19:15.280
api without documentation or incorrect documentation uh it's it's
00:19:21.120
uh impossible um one thing that we've done and there's some api tools that i
00:19:26.320
want to talk about uh uh also uh but uh that can help with this one thing that we did is we wrote a simple like dsl
00:19:32.320
for a documentation um uh it's basically uh encapsulates an api setting uh with
00:19:38.960
various things and we can turn this into like rich documentation and we can reuse this stuff all over the place so we can give like code examples
00:19:45.360
that are automatically generated just from a little bit of simple information and it's not that hard to do and it's
00:19:51.039
really really appreciated by users of an api
00:19:56.960
the one thing that we're not doing here i think the next step on on this would be actually connecting the api
00:20:03.200
documentation to validation and implementation of the api itself so the api spec and documentation
00:20:09.120
are in sync across the board um has anyone ever done that within api
00:20:17.840
how did you guys do it um
00:20:46.840
right um next tip this is really simple but
00:20:54.640
uh provide libraries so provide a simple ruby wrapper for your api even if it's a clean clear api a simple ruby wrapper python
00:21:01.600
wrapper php java et cetera it's not that hard to build um and it can
00:21:07.440
make integration that much easier um support your api
00:21:14.480
and there's a there's a simple reason for that and that's that apis are kind of scary an api represents uh
00:21:20.240
someone else's responsibility so something that you don't have control that's injected into your application
00:21:26.080
um it's extremely powerful but it's also can be frightening and and if you're using someone's api and they don't
00:21:32.640
respond to email and then they they don't help you out uh it's it's not it's not a stable
00:21:37.840
position or a stable relationship um next make it fast uh an api should never
00:21:45.360
slow down an application so there's a few things you can do here uh get requests can often be cached using
00:21:51.520
um this the same things that can speed up a web site can easily speed up a web service
00:21:58.720
application um just as a principle one of the things that we try to do is
00:22:03.919
not let one person's api requests affect someone else so if one person's flooding you with api requests that should not
00:22:10.000
uh slow down things for other people
00:22:33.600
okay so yeah there's two sides to making something fast in in the case we have an asynchronous processing api one side is
00:22:39.600
accepting the request in the first place or handling a request and the other is doing the work i think both are absolutely true um i'd
00:22:45.760
say this i'd be referring more to you accepting the request in the first place although on the other side i mean so we
00:22:52.240
deal with this problem and we have you know our queuing algorithm doesn't let one person's
00:22:58.480
load um uh slow down other people's systems so so if you send you know a thousand jobs
00:23:04.799
it's not going to block everyone else from doing things
00:23:32.159
that resource is going to continue to return something
00:23:57.279
that's a interesting way of doing handling a long running process using a redirect to the resource when it
00:24:02.960
when it shows up then it's done i see it right and plus of course
00:24:13.840
yeah yep sure
00:24:28.480
because i assume that's one of the biggest challenges
00:24:40.880
yeah so so i think i think um the the the size of files that we deal with the
00:24:46.159
length of time it takes to process ultimately you you can make that totally orthogonal to the performance of the api
00:24:51.840
so we we do something kind of like uh uh that we don't actually do a redirect to the resource uh when it's finished but when so our
00:24:59.440
our processing takes anywhere from a few seconds to a few hours uh we will as soon as we get an api request
00:25:05.360
we will send a response that says uh record created so job created or video created
00:25:11.279
uh will give a pointer to the file where it will appear when it's done and a job id that
00:25:16.720
you can reference so you can pull our api uh check the job id you can pull the location of the file see if it's there
00:25:22.400
um and we do a callback so we can after processing we can send a call back to a
00:25:27.440
url that says job finished um so dealing with big files
00:25:32.720
um is uh interesting uh uh but but it doesn't it
00:25:39.360
doesn't affect uh this is does that make sense
00:25:46.640
um so kind of a similar concept to this is uh consider rate limiting who knows what this is
00:25:56.640
uh this is basically a denial of service attack uh that someone could easily accidentally do uh uh uh just
00:26:02.960
loop through hitting your api over and over and over and over and over and depending on how fast you resp well uh and depending on how fast you
00:26:08.960
respond or or the conditions under which this happens this can be really bad um so rate limiting is a simple way to
00:26:15.520
uh not let someone make the same request too frequently or the same you know one
00:26:20.799
user make too many requests you frequently um log requests
00:26:30.320
we um it's it's really simple to uh to keep a
00:26:36.880
record of every api request that comes into a system and that can be really useful information when you're trying to set up
00:26:42.159
integration or when you're trying to troubleshoot why something's going wrong so we only keep this around for about 24 hours
00:26:47.679
but someone can come in and say and look at every api request that they've sent and if one doesn't work they can go in
00:26:53.039
and get information of what was the request body that was sent and what was the response that was sent and it makes it it helps with
00:27:01.360
digging into problems we have a similar tool uh um it's
00:27:07.440
basically an api request builder um our api is a uh
00:27:13.200
kind of a write heavy api we've got 100 settings in the system so we built this tool where you can
00:27:18.720
choose the settings from a user interface and it'll actually populate what the json is that that that
00:27:24.640
uh um that that creates that so you can just copy and paste the json there and uh uh plug in your application
00:27:32.720
and that's your api integration so i i think the the um the
00:27:40.080
the point is there's a lot of tools that you can build for users apart from just sort of documentation apart from at the user
00:27:46.320
level and not the api level that can make apis much more interesting to work with
00:27:51.840
and faster um so that that that's about a dozen a
00:27:57.279
dozen ideas for for api design uh two questions wha what other um
00:28:02.960
what other thoughts do you all have for what makes a good api uh and two there's a number of tools
00:28:08.320
that are coming up um uh libraries that that help uh uh with apis has anyone successfully used one or
00:28:14.880
found one that's been helpful it was actually pretty much what your first line is which is make your api
00:28:21.919
documentation right where you would go to to get the api
00:28:27.200
like we all hate soap but that is actually one thing that someone can do is if you go to the soap url it will
00:28:34.320
usually have some type of documentation you don't have to find any of this or have a url and you can go there
00:28:40.720
because you're going to accept html in that case
00:28:46.320
that's interesting so accepts html yeah a lot of purists really emphasizes that
00:28:54.000
at least what i've read by the guy who did rest said that you're not really doing restful api
00:29:00.640
unless you're returning links with each response showing where the person could
00:29:06.640
go from here this is why i like xhtml as a return for my api because then you can actually just
00:29:12.159
literally browse the api in your web browser and put the human readable documentation alongside the mechanical representation you get
00:29:18.480
both simultaneously there's a reason to be aggressive so so would the with the get url show the structure of the post and put a
00:29:25.600
requests as well yeah or would you actually in the actual html because that's part of the response so you'd be
00:29:30.640
able to say like you know blah blah blah and put all your documentation show all the different actions you can do
00:29:36.000
cool that's a good idea try to treat api changes like database migrations
00:29:41.039
in the sense that i try to make these backwards compatible only have never deleted if at all possible yeah
00:29:47.440
that's that's a good principle although it's so easy to migrate in rails and uh
00:29:56.799
have you ever run into issues with any of your customers having problems with methods again
00:30:05.120
what's uh having problems understanding a put for example that's a good question um are there some
00:30:10.720
frameworks that don't play well with non-git and post customers
00:30:16.720
with posts we've not seen that
00:30:24.880
i ran into patch method required by the salesforce api to update
00:30:30.399
the records this patch patch is a bird yeah
00:30:39.120
was added relatively recently the github api uses a degree of fact there are more than four curves
00:30:48.320
there's like but it does get tricky it's a definite concern like a lot of people don't
00:30:54.559
handle things even people that are good about handling getting posts sometimes do a problem and delete and you know then the other
00:31:00.640
ones like nobody knows so there's no support
00:31:08.080
so should we design our api to accept more than one verb for the same action
00:31:14.240
um that does the same thing so you have a an alias to a name right so you've seen people mix
00:31:22.080
what posts i do all the time right it would be a kind interface but you just got to be careful with that this
00:31:27.279
thing was called iv6 we tried this already
00:31:41.039
html spec does not allow you to put anything that would get a post into an html form so rails has to do all the financing
00:31:46.720
with the understand method and that's like a balance between like the standard and what we're trying to accomplish so
00:31:52.240
you always have to be playing that juggling game is incredibly specific i don't think there's any broad right answer for all cases yeah
00:32:04.000
we've never had critical trouble with put or delete i'd say those four at least are safe for an api for a web service api
00:32:11.039
others use your judgment seems like a language where everybody
00:32:16.880
knows about 1020 but uses everybody's communication is there any
00:32:22.080
point in history where we had where there was something similar and they solved it or they were they moved
00:32:28.880
it seems like there's a lot of miscommunication and missing pieces with rest they're there somewhere but a lot of
00:32:34.799
people don't know those pieces and yet we use it for communication all the time so is there something we
00:32:39.919
can look back to and say oh this is how they solved it and this is how they made it better
00:32:45.519
any ideas for that question
00:33:05.279
uh i mean i would say that the seven layers
00:33:31.440
html validator how much of the web do you think would actually like pass html validator right it's the exact
00:33:38.159
same problem like you know we make standards and we sort of kind of all happen and then sometimes with like
00:33:44.399
html5 standards are not even centrally made efficiently so they become ad hoc standards that that
00:33:50.240
uh yeah um what what about tools uh someone mentioned great has anyone used
00:33:55.440
the grape library i've heard it before what what what's your
00:34:05.120
for building experience uh trivia and then it has a nice little psl
00:34:14.560
it looks very siddhartha um
00:34:32.839
um
00:34:46.320
any other tools that people find helpful so are you using any tools for metering and uh limiting uh not any tools it's it's
00:34:55.520
it's frankly a little ad hoc right now
00:35:01.200
yeah has anyone used apogee
00:35:06.880
there's there's a number of services and startups too that are that are being built around this concept so it's an
00:35:12.000
interesting interesting space to watch um okay let's uh we can uh talk more at
00:35:18.560
the end let's uh let's get uh to the um final section here i i uh the the the
00:35:23.680
title of this talk um uh uh made uh uh said that this talk would help you make friends
00:35:29.680
get rich and change the world so uh before you accuse me of over-promising i
00:35:35.200
want to try to justify that first how can an api help you make
00:35:41.119
friends um so here's a tweet uh uh redacted is so awesome that i'd like to offer their developers
00:35:46.640
free hugs uh so this is someone that uh had never met um uh redacted and offered
00:35:53.040
physical affection um uh based on their experience with the api um i think there's a reason for this and
00:35:58.800
it's that when you're dealing with so if a when you're dealing with developers and b especially when you're dealing with
00:36:04.160
something like an api awesomeness is noticed um there there's a there's probably some
00:36:09.200
like fancy economics uh term for this phenomena that i'm going to try to describe i have no idea what it is so i'm going to pretend that it's
00:36:15.119
called asymmetrical value curve um so uh uh uh
00:36:22.320
imagine this concept so so as as quality increases the value to the person who experiences that quality in this curve
00:36:28.880
increases linearly there's other phenomena that kind of follow this kind of pattern where
00:36:35.680
really really high quality is not that much more important than okay quality and there's some things that follow this
00:36:40.880
phenomenon where until you get to the very very best uh it doesn't really make that much of a difference
00:36:45.920
um so a few examples um bus driving i would say follows this curve uh just
00:36:52.160
imagine for a second like the best of all possible bus drivers um not like a bus stop who fights crime
00:36:57.680
just just in their capacity uh as a bus driver how much better is that than the median bus driver
00:37:04.480
um whereas the worst of all possible bus drivers is significantly worse than the media
00:37:11.280
other things follow the opposite pattern i would say sports follows this pattern michael jordan is not just a little bit
00:37:17.520
better than the best basketball player at the ymca he's a million times better or whatever
00:37:22.880
it is in in terms of value um i would say art follows the same pattern so you know the the the
00:37:28.640
uh your your friend who's the best at art is probably not nearly as good as um the as as you know michelangelo
00:37:36.560
um api design i think follows this kind of a curve and actually i think a lot of design in general does too user design product
00:37:43.839
design um but but just just incremental improvements uh from good to great from great to
00:37:49.040
excellent etcetera make a really really big difference um and that's that's how you can make
00:37:55.280
friends so so what one more one more uh uh um email uh
00:38:02.839
uh yeah we got this out of the blue one day um i know the following statement is going to sound dramatic but it's the
00:38:08.560
truth um redacted seriously uplifted my entire day the api is really well designed it has
00:38:13.760
documentation not only for what each value blah blah blah so when i started digging into redacted i felt like i was
00:38:18.880
witnessing a double rainbow uh then when i found the api builder it went beyond a double rainbow to a level
00:38:24.079
i can only imagine is equal to witnessing a uniform unicorn
00:38:29.280
so that that's a lot of enthusiasm over an api
00:38:36.000
uh it's confidential so
00:38:41.359
second an awesome api can help you get rich has anyone heard this phrase
00:38:47.760
software is eating the world um uh mark andreessen
00:38:52.960
has wrote an article called this recently he's the creator of mosaic netscape
00:39:00.800
uh firefox or mozilla et cetera big eye in software and basically the idea is that we're at
00:39:07.359
this sort of early stage of software taking over more and more parts of uh the structure of the world
00:39:14.560
so think things that previously had nothing to do with software whatsoever are being replaced by software in some ways
00:39:20.880
um so airbnb is software that replaces hotels um zipcar is software that
00:39:27.520
replaces car ownership um and and and his idea uh and he's now a venture
00:39:33.920
capitalist and manages you know a billion dollars of of money his idea is that that this is an accelerating trend
00:39:40.160
and that software is going to keep eating more and more of the world there's huge opportunities uh for people to take software uh and
00:39:46.560
put it in place of something that previously was not uh done by software uh there's some study um
00:39:53.599
that says that there's gonna be 80 billion dollars in new spending in cloud computing over the next i guess now the next three years
00:39:59.200
it's a lot of money um there's a lot of companies that are are doing this kind of thing right now
00:40:04.240
so if you're looking for something to do if you're looking uh to get rich or just to build a product
00:40:11.280
build a company consider making an api to something um if you're looking for ideas uh here's
00:40:18.400
a few an api to ruby so pi cloud is a pretty cool idea um be interesting to see that done with ruby um what about an api
00:40:26.800
uh pi cloud um so pi cloud uh is an api to python processing so you can basically take a bit of
00:40:32.640
python code and run just that that normal python code distributedly uh in the cloud um what about an api to
00:40:39.920
the government um who who likes interfacing with the government uh who likes going to the dmv and like
00:40:45.599
filling out forms uh uh what when i build an api to like every irs form or every government form that
00:40:52.079
ever has existed or api to uh those kind of things you require a
00:40:58.079
different http status code for bureaucracy yes that's right and you can tell us
00:41:12.160
uh or another idea what about an api to manufacture um so amazon ec2 is an api to like limit
00:41:19.280
servers for windows servers what about an api to like a thousand uh 3d printers or an api cnc routers or an api laser
00:41:26.800
cutters it's still a little too early i did this as a startup and it's still too early but it's awesome and it's a query
00:41:34.079
at some point someone's gonna figure this out and it's gonna be amazing it'll be definitely super sweet
00:41:39.440
yeah yeah
00:41:46.839
um slash post-modern argument to be made about software in the world
00:41:52.720
which requires that the space in which swimming items are considered fungible and
00:41:59.440
interchangeable so the zip car works only so far as the purchaser has no consciousness about the semiotic
00:42:07.280
value of a bmw versus a cooper mini although
00:42:13.200
sure and the tokenization and the representation and semi-auto value say being a zipcar car also has a
00:42:20.160
certain cachet but i think something andreessen's not picked up on because he's healthy
00:42:27.920
subtle social cues that may impede entering these markets so if anyone's inspired by this be sure to take
00:42:34.640
into consideration the sociological import of the science and their appearance signifies any thoughts on
00:42:42.839
that that's a philosophy degree's worth just right there 15 years to bust that
00:42:48.240
out well i just say some people don't like talking to
00:42:53.280
us i'll take a stab at it and just say that um like i think that
00:42:59.359
perhaps there he may not have had a sophisticated response or have or
00:43:05.520
delved into that a lot that i think that there's no reason why zipcar for example couldn't make that
00:43:12.160
decision couldn't uh care more about those things i don't think i think that's orthogonal
00:43:17.920
to the api or to the fact that software eating the world and actually you you can get a bmw on some cards like two bucks an hour
00:43:24.160
more than your your ford or whatever you can rent a lamborghini right so so really the difference is
00:43:30.720
that really the fungibility would be one bmw to another so it doesn't have to be my bmw it could be any bmw
00:43:36.400
and all this stuff does have some degree of like
00:43:41.920
commoditization is kind of a side effect of this kind of thing not not not that every car becomes the same but that
00:43:47.680
you know a car provided by zipcar and car provided by someone else or this car or that zipcar car theoretically it
00:43:53.760
shouldn't be you shouldn't have to worry about which one yeah i mean ultimately software could model the real world it does it and
00:44:00.720
perhaps it will someday you know i mean there's no reason why sure yeah this is
00:44:06.960
blogger's seminar simulation which had cameo in the matrix but basically the opening question is what would happen if you
00:44:13.119
ever created a map that was so perfect that it was a one-to-one relationship
00:44:18.560
would you need the original anymore and what would be economic
00:44:31.680
like manufacturing api our entire economy and sense of what value is is based on things being scarce so
00:44:37.119
when i can print a car why would i ever like buy one from hamburger so there's a lot of really interesting
00:44:42.720
implications to like the future and bar that goes
00:44:51.440
so uh um last claim was that api's awesome apis can help you
00:44:56.560
uh change the world so let me try to justify that um uh remember the dot-com bubble um
00:45:03.920
companies raised you know millions and millions of dollars uh without having revenue or product or an
00:45:10.400
idea um and and most of that was a bubble but there was actually some fundamental
00:45:16.640
fundamental reason for that and that's that back in 1998 it was really expensive to run internet
00:45:22.720
software it was really expensive to start a software company you had to pay larry ellison a lot of money and you had
00:45:28.319
to pay a son a lot of money uh so mark andreessen in this article says in 2000 the cost of a customer
00:45:33.520
running a basic internet application was approximately 150 thousand dollars a month running the same application today on
00:45:39.920
amazon's cloud cost about fifteen hundred dollars a month that's a hundred to one uh uh price
00:45:45.200
decrease what caused this phenomenon
00:45:52.480
uh so so for for this revolution it was linux and it was richard stallman um today you can run free software
00:46:00.640
that is not only better than the most expensive software was 10 years ago it's better than commercial software
00:46:06.720
that you pay for today uh and that that that's a huge transformation in the world of software
00:46:12.480
it basically empowers developers small teams smart people to do interesting things
00:46:18.480
previously you had to go to these guys the harvard mbas and ask them for money if you wanted to
00:46:24.160
do something they got rich and became vcs and they were the gatekeeper to being able to do interesting things
00:46:29.680
that's not true anymore now the model for funding is twenty thousand dollars from paul
00:46:35.200
graham and a chance to sit and hack on something for three months and that and you can build amazing things with just
00:46:40.480
that or you don't raise any money at all and and you build a impressive company
00:46:46.800
with a small uh group of people this is the phenomenon that lets uh mark
00:46:52.160
zuckerberg and justin timberlake change the world uh and build a billion-dollar company
00:46:58.400
in a dorm room so if um richard stallman was the uh
00:47:05.440
revolutionary of the last 10 years what's the revolution of the next 10 years
00:47:12.160
i'd say it's amazon web services i think this does a very similar thing that uh to the world that open source
00:47:18.079
software did um previously uh uh uh you you if you wanted a thousand cpu
00:47:24.160
cores you had to like set up a big data center and pay millions of dollars or whatever it would be now you can get a thousand
00:47:29.760
cpu course for a day for 204 if you have 50 phone numbers you
00:47:34.960
can get 50 phone numbers for 50 a month uh and that's a pretty
00:47:40.160
amazing revolution that that is just at the beginning uh uh more and more uh
00:47:47.440
more and more technology and power and functionality is gonna be given to small groups of people small teams to be
00:47:54.160
much more productive thanks to this and i'd say this is the revolution of the next 10 years
00:47:59.680
so uh takes power away from these guys and gives it to small teams it also means that the next
00:48:06.559
big innovation is less likely to come from steve ballmer and microsoft and it's
00:48:12.079
more likely to come from this guy so thank you
00:48:59.839
you
