00:00:15.689
all right okay I think we are ready to
00:00:19.660
get going thanks so much to everyone for
00:00:22.119
being here this is both of our first
00:00:24.760
times at railsconf and we're super
00:00:26.260
excited to be here as well it's been a
00:00:28.689
fast a fantastic week so fantastic that
00:00:31.029
I'm losing my voice and I've gotten a
00:00:32.500
little cold so please forgive if I had a
00:00:34.239
crackly voice I'm all hopped up on cold
00:00:37.180
meds so there should be an entertaining
00:00:38.969
presentation anyway so my name is Rosie
00:00:41.860
and I'm joining you here from
00:00:42.969
Minneapolis and this lovely lady here is
00:00:45.190
Sonja all the way from Washington DC and
00:00:49.289
today Sony and I are going to talk about
00:00:51.940
api's but we're going to take a slightly
00:00:54.309
different approach to this talk we both
00:00:57.250
have been through fairly major career
00:00:59.320
pivots in the past few years that have
00:01:01.239
led us to be in front of you here today
00:01:02.860
as rails developers so we wanted to take
00:01:05.860
all of our past experiences and use this
00:01:07.869
to kind of frame this conversation in a
00:01:09.820
way that we thought might be relevant
00:01:11.680
and interesting so my background before
00:01:14.049
I made the transition to rails
00:01:15.610
development was in architecture as in
00:01:18.580
bricks and steel architecture not
00:01:20.229
software architecture and city planning
00:01:23.130
sony also worked as a writer and graphic
00:01:26.140
designer in a former life we've both
00:01:28.750
spent a lot of time thinking about the
00:01:31.720
building process and design elements so
00:01:35.890
to start at this presentation I'm going
00:01:37.360
to talk a little bit about the
00:01:38.799
importance of patterns in both the built
00:01:41.229
environment and in software that support
00:01:44.049
good design then I'll get into the need
00:01:46.930
of the talk and describe why we think
00:01:49.119
you should consider building the API
00:01:51.189
first and Sonja will go over some best
00:01:54.340
practices and I'll bring it home with a
00:01:56.829
bit of conversation about some tools and
00:01:59.140
best practices that you can use to build
00:02:01.630
your API
00:02:08.369
so as I mentioned my background before i
00:02:10.990
got the wild hair to become a rails
00:02:12.580
developer was an architecture and
00:02:14.380
planning along the way learning to
00:02:16.750
program and learning rails has been a
00:02:18.310
fascinating journey partially because
00:02:20.680
everywhere I look I find these parallels
00:02:23.410
between the built environment and the
00:02:25.900
rails software stack one of these
00:02:27.910
parallels is the role that patterns play
00:02:30.400
in both of these worlds before we dive
00:02:32.800
into the meat of this talk I want to
00:02:34.300
tell a quick story about how I came
00:02:37.000
around to this topic and why we thought
00:02:39.430
it might be relevant to approach this
00:02:40.810
topic from the perspective of design
00:02:42.640
patterns one of the most influential
00:02:45.820
books in the last half a century and
00:02:47.590
architecture is this book by Christopher
00:02:50.080
Alexander a pattern language if you're
00:02:52.690
unfamiliar a pattern language in a
00:02:55.030
nutshell is a method of describing good
00:02:57.850
design practices a pattern language
00:03:00.550
should facilitate successfully solving
00:03:02.950
very large complex design problems these
00:03:06.850
patterns are tools to help abstract away
00:03:09.250
some of the complexity in our worlds or
00:03:11.739
little brains can wrap around how to
00:03:14.320
approach solutions design patterns in
00:03:17.200
the built environment go back hundreds
00:03:19.150
and hundreds of years and are very much
00:03:21.310
so rooted in how we as humans experience
00:03:23.230
our surroundings and relate to each
00:03:25.090
other and for me as an architecture
00:03:27.940
student understanding patterns was a big
00:03:29.860
part of my training I'm sure you all
00:03:33.489
guessed where this is going so this book
00:03:35.920
came out in 1977 in response to a few
00:03:39.010
decades a really really bad architecture
00:03:41.170
that just went in the face of good
00:03:45.160
design patterns that had developed over
00:03:46.870
the ages they ignored these patterns
00:03:49.000
that support the tried and true way
00:03:51.340
humans want to inhabit cities and
00:03:53.790
essentially ended up creating a lot of
00:03:55.900
buildings that were really awful spaces
00:03:57.970
for humans so now we fast-forward 20
00:04:01.390
years and these ideas reemerge in the
00:04:04.870
software world and martin fowler for
00:04:07.000
example is writing about patterns not
00:04:10.090
only is you writing about patterns all
00:04:12.130
of the language that he uses to talk
00:04:14.110
about object-oriented software design
00:04:15.730
come straight out of the ARCA
00:04:17.680
sure world on this book's Wikipedia page
00:04:20.769
they point directly to Christopher
00:04:22.150
Alexander's book as an inspiration or
00:04:24.580
Fowler's work and software most people
00:04:27.370
probably take it for granted at this
00:04:28.900
point but all of the language that we
00:04:30.699
use to talk about software was lifted
00:04:33.190
straight out of the architecture world
00:04:34.509
and as an extension I think the way the
00:04:37.750
profession thinks about the organization
00:04:39.850
of things we like to think that what
00:04:42.550
we're doing is new but take a couple
00:04:44.770
steps back and the concepts are really
00:04:46.990
the same I don't know a Fowler and
00:04:50.770
Alexander knew each other but I think
00:04:53.020
they would have gotten along and one of
00:04:54.520
the things I like to imagine is them
00:04:55.960
going out on Tuesdays to drink
00:04:57.940
cappuccinos and to have these really
00:04:59.740
intense philosophical conversations
00:05:01.780
about the order of things even though i
00:05:05.830
had a glance it seems they come from
00:05:07.150
very different worlds at a conceptual
00:05:08.620
level i think they would be having the
00:05:10.060
same conversation so coming back to
00:05:14.770
rails when i started to think about
00:05:16.570
software I never Lee brought this lens
00:05:18.639
of patterns with me which meant i was
00:05:21.699
super primed to drink the rails kool-aid
00:05:23.970
convention over configuration obviously
00:05:27.130
this was just really smart design these
00:05:29.830
conventions mapped very cleanly in my
00:05:32.020
brain to patterns and I just got it
00:05:34.599
right away at first the process of
00:05:37.900
learning rails was just a smooth
00:05:39.370
progression of these elegantly designed
00:05:41.680
pieces sort of clicking into place then
00:05:44.970
inevitably I stumbled into area after
00:05:48.340
area where rails does not provide
00:05:50.340
conventions or strong opinions on what
00:05:52.630
to do and I would look to my right
00:05:54.759
looked at my really left talk to
00:05:56.139
developers around me and realized
00:05:58.630
everybody had a different opinion and
00:06:00.520
honestly this is when learning rails got
00:06:02.229
kind of hard and so this brings us here
00:06:05.949
today one of these areas that I that we
00:06:09.639
found without a clear sort of mainstream
00:06:11.949
convention that everyone seems to agree
00:06:13.570
on was api's beyond using jbuilder and
00:06:16.990
the basic happy path rails application
00:06:19.000
there wasn't clear guidance how to deal
00:06:21.849
with api's and honestly this really
00:06:24.400
surprised me and seems to me and maybe
00:06:27.490
many of you
00:06:28.620
most of the hard problems I deal with
00:06:31.029
today are related to data transfer at my
00:06:34.569
current job this is what we do we build
00:06:36.309
applications that manage large amounts
00:06:38.319
of data this is a really important piece
00:06:40.180
of our applications and so thinking
00:06:44.229
about this more as developers as a new
00:06:46.749
developer i should say when we have a
00:06:48.279
question I've course asked the internet
00:06:50.939
this sent me down a rabbit hole where
00:06:53.529
everyone was suggesting something
00:06:54.789
slightly different and nobody seemed
00:06:56.919
quite satisfied with how they were
00:06:58.389
dealing with this problem I read about
00:07:00.249
lots of solutions all having varying
00:07:02.379
degrees of success I was all interesting
00:07:04.810
and somewhat helpful but wasn't the
00:07:07.449
solid answer I was looking for and he
00:07:11.349
was really frustrating I knew this
00:07:13.509
wasn't rocket surgery and left me
00:07:15.279
feeling like okay rails if you're so
00:07:18.639
opinionated why don't you have an
00:07:19.870
opinion on this what should I do and and
00:07:23.099
so here we are and we believe building
00:07:28.719
API is is one of the critical error
00:07:30.189
critical areas where we should have a
00:07:32.589
shared solution because obviously this
00:07:36.039
is how our applications talk to each
00:07:37.899
other this is where my application and
00:07:40.599
your applications cease to be my problem
00:07:43.449
and your problems and they're not
00:07:45.370
everybody's problem especially if we
00:07:48.159
have a public API so for one moment
00:07:52.089
bring this back to Architecture the
00:07:54.879
evolution of our great cities is really
00:07:57.249
the evolution of shared problems
00:07:59.069
becoming shared solutions and elegant
00:08:01.779
and innovative ways we tend to think of
00:08:04.419
the development of cities in terms of
00:08:06.069
buildings but buildings come and go in
00:08:07.810
reality the interesting story and here I
00:08:10.360
take off the architecture hat and put on
00:08:11.979
the city planner hat is is really the
00:08:14.259
story of infrastructure how we came
00:08:16.330
together and agreed how electricity
00:08:18.490
should be delivered how our sanitation
00:08:20.889
systems should be constructed and how we
00:08:23.289
wanted to get from point A to point B so
00:08:28.659
the starting point of this talk is that
00:08:30.610
api's should act as the infrastructure
00:08:32.919
for our applications if passing around
00:08:36.339
data is the most important thing your
00:08:37.930
app does and your API is should be
00:08:40.000
elevated from something we hobble
00:08:41.409
together
00:08:42.230
to something that we have a solid
00:08:43.850
solution for and starting with the API
00:08:47.090
and building your client applications
00:08:48.920
around it opens up all sorts of
00:08:51.110
interesting possibilities carry it out
00:08:54.140
to the full realization of this concept
00:08:55.910
your api's could be the foundation that
00:08:58.730
supports a variety of clients such as
00:09:00.710
mobile applications or rich JavaScript
00:09:04.130
framework clients by decoupling your
00:09:06.890
rest api from your client you can more
00:09:09.680
easily support multiple clients and have
00:09:12.050
a system that is much more flexible but
00:09:14.360
also organized if a mobile interface is
00:09:19.610
really important to your application
00:09:21.500
your rest api can support multiple
00:09:23.540
native mobile apps with minimal
00:09:25.730
duplication across platforms this is a
00:09:27.800
good thing you can also use the same API
00:09:30.500
to serve data to a JavaScript framework
00:09:32.360
again with very little duplication your
00:09:36.740
API should be the common denominator
00:09:39.190
without a good standardized server
00:09:41.480
solution you can't have a standardized
00:09:43.370
way for different clients to talk to the
00:09:45.560
servers all right we've discussed some
00:09:48.920
reasons why for this new generation of
00:09:51.020
rails applications that must embrace a
00:09:53.360
variety of clients the API should be the
00:09:56.000
foundation and where we think you should
00:09:58.790
consider starting so one your
00:10:02.750
application will be designed to pass
00:10:05.360
around data from the get-go and reason
00:10:08.090
to if you need to support multiple
00:10:09.830
clients you can easily do this with
00:10:11.720
minimal duplication across platforms and
00:10:14.110
three if you create the standardized
00:10:17.120
server code first you'll easily support
00:10:19.250
the creation of standardized client code
00:10:21.230
ok now I'm going to pass it off to Sonja
00:10:28.930
so let's discuss some of the API best
00:10:32.630
practices there are a few that are very
00:10:35.270
important to begin with when you're
00:10:37.220
constructing your API but Before we jump
00:10:39.440
into them I think it's important to
00:10:41.180
consider this question why is a
00:10:43.700
well-designed API so important well in
00:10:49.130
this image we see falling water going
00:10:52.610
back to architecture just for a moment
00:10:53.870
this is a cantilever home in
00:10:55.460
Pennsylvania built in 1935 that is among
00:10:58.190
one of the greatest assets to the
00:10:59.780
architect and design think of Frank
00:11:01.250
Lloyd Wright it is built partly over
00:11:04.160
waterfall driving its name from its
00:11:05.600
situation and will and has been
00:11:08.390
conserved as a museum now since 1963 so
00:11:11.270
in other words this is a huge asset to
00:11:14.450
the legacy of Frank Lloyd Wright a
00:11:17.600
well-designed API can be that of a
00:11:19.640
company's greatest assets why because
00:11:25.340
users invest their time and obvious and
00:11:27.140
not so obvious ways in the obvious ways
00:11:30.170
you're writing to it buying products
00:11:32.990
that use it you tell your friends and
00:11:35.030
communities about how great this API is
00:11:36.680
you start writing blog posts about it
00:11:38.450
you're creating hype basically the less
00:11:40.700
obvious ways and is that the users are
00:11:42.680
digging into it and spending a
00:11:44.090
significant amount of time learning how
00:11:46.520
it works and playing around in the code
00:11:48.050
a poorly designed API can be a huge
00:11:51.920
liability the same users who would have
00:11:54.410
been promoting it and using it as
00:11:55.970
inspiration for new products are now
00:11:57.440
calling it calling in for support and
00:11:59.510
asking you what to do about the problems
00:12:02.240
that you've created with the API and
00:12:03.740
taking away from your productivity or
00:12:06.110
worst case scenario they're just taking
00:12:08.000
one look at your API and then running
00:12:09.500
away from it so the first guideline to
00:12:12.050
follow of the breath best practices is
00:12:14.720
to design your AP is for experience
00:12:16.820
rather than and readability not for data
00:12:19.160
alone in other words an API should
00:12:21.950
reflect how something is used not just
00:12:24.380
how it is stored in fact I hate to say
00:12:27.110
it but nobody really cares what your
00:12:28.850
database looks like people want to know
00:12:31.400
how it operates how they can use it the
00:12:33.950
experience should not fill your fellow
00:12:35.420
developer with misery or regret it
00:12:38.090
should be methodical and can
00:12:39.710
assistant which leads me to the next
00:12:41.870
best practice of consistency by
00:12:45.080
providing a single API that can serve
00:12:46.790
multiple clients you get consistent
00:12:49.490
client solutions across platforms this
00:12:52.400
includes having single endpoints and
00:12:54.140
clean routes throughout your API it's
00:12:56.480
kind of like a telephone pole with all
00:12:57.890
the cables and wires running through and
00:13:00.380
around it the pole is built with
00:13:02.810
specific plug-ins for specific wires and
00:13:05.330
purposes allowing electricity to flow
00:13:07.100
from the power plant to your computer
00:13:09.560
screen or your light bulb or what have
00:13:11.270
you and similarly an API call retrieves
00:13:14.030
a particular data set from your database
00:13:15.860
and expects a consistent return every
00:13:18.290
time without this we get this the
00:13:22.340
alternative something hideous and
00:13:25.310
terrifying unfortunately this slums
00:13:29.180
infrastructure does not support
00:13:30.980
consistency or a sustained development
00:13:32.510
of regulated wiring it is in efficiency
00:13:35.840
at its finest where everyone seems to
00:13:37.670
abduct it adopted to each their own
00:13:39.800
mentality you should never have your API
00:13:43.370
making someone feel like this so avoid
00:13:46.040
that coming from the writing and editing
00:13:48.020
world documentation is so important
00:13:51.110
especially having learned how to code
00:13:53.510
later in life I love a well-documented
00:13:57.490
gem or you know anything I'm trying to
00:13:59.990
use I love when I see a lot of
00:14:01.310
documentation and written the right way
00:14:04.030
so documentation is very important to
00:14:07.040
the widespread use of your API public or
00:14:10.280
not it should act as a bonus layer of
00:14:12.470
information though like a glimpse into a
00:14:14.660
developer's mind that assumes nothing
00:14:16.760
and notes everything it should sit on
00:14:19.250
top of an already easy-to-understand API
00:14:21.590
and so in other words don't make the
00:14:24.050
documentation do the dirty work your API
00:14:26.750
should already be understandable and
00:14:28.370
you're just providing this layer of
00:14:29.600
documentation on top of it so if you're
00:14:33.650
the type we're just grumbled at my last
00:14:35.210
slide I know you're out there let's chat
00:14:37.790
about a service that makes documentation
00:14:39.620
a cinch one that we found was apiary
00:14:42.640
it's a structured interactive tool that
00:14:45.320
follows the necessities documentation
00:14:47.390
using markdown and a template for easy
00:14:49.850
use
00:14:50.370
the result is an intuitive document
00:14:53.850
incorporating the basic necessities that
00:14:55.529
all documentation could contain should
00:14:57.480
contain so here's an example of apiary
00:15:00.470
and what it might look like when you're
00:15:02.400
doing it but generally speaking APR
00:15:05.460
you're not all documentation should
00:15:07.110
include the following examples of the
00:15:09.810
full request and expected response a
00:15:11.820
list of error codes their significance
00:15:14.790
like what is causing them a searchable
00:15:17.700
HTML interface and communication of
00:15:21.930
versioning and deprecation schedules so
00:15:24.000
you don't catch anyone off guard who
00:15:25.470
happens to be using an API a version of
00:15:28.470
your API that you're going to be moving
00:15:30.450
forward from so the lifespan of an API
00:15:34.170
is important to consider it can be
00:15:37.050
difficult to choose how you're going to
00:15:38.730
version or what your strategy will be
00:15:40.830
but you should approach it as if you
00:15:43.050
have to get the first one the first
00:15:44.670
version of your API absolutely right it
00:15:49.050
makes it easier down the road the most
00:15:52.170
important thing though to remember is
00:15:53.430
that versioning is inevitable and plan
00:15:57.420
for deprecation from version 1 I also
00:16:03.120
like to think of api's as if they were a
00:16:06.120
rescue dog if anyone knows me from
00:16:08.580
flattering school and see if you go out
00:16:09.839
there I'm obsessed with rescue animals
00:16:11.550
so I had to tie this back in for a
00:16:13.440
moment um so this is not a Westminster
00:16:16.320
Kennel Club winning da but dog but um
00:16:18.510
it's more like a little rescue pup he
00:16:21.779
has limitless potential to be an
00:16:23.459
incredible pet if you let him get there
00:16:25.110
just like you want to set your future
00:16:27.570
dogs up for success you'll want to do
00:16:29.880
the same for your API for starters
00:16:32.310
neither this dog or your API require any
00:16:34.950
fancy things they simply crave
00:16:36.959
repetition and unconditional support in
00:16:40.110
order to be successful give them what
00:16:42.390
they need to involve into their new
00:16:43.860
versions but don't ever forget where
00:16:45.990
they came from the JSON API is one
00:16:50.459
standard for building api's and JSON
00:16:52.320
that is supported by the rails community
00:16:54.200
so this is Steve cloud Nick's quote by
00:16:58.200
following shared conventions you can
00:16:59.670
increase productivity take advantage of
00:17:01.560
generalized tooling and focus on what
00:17:03.570
Matt
00:17:03.900
there's your application and we liked
00:17:07.080
the JSON API standards so I put an
00:17:10.050
example of it here and like so many of
00:17:13.650
the tools that we've discussed already
00:17:16.230
today there are more out there and
00:17:18.300
there's a lot of great ones being
00:17:19.440
developed right now so Rosen's going to
00:17:21.720
share a few more of those with you so
00:17:28.670
building API is is a shared problem for
00:17:31.380
most developers it seems there is now a
00:17:33.720
general shared understanding of what a
00:17:35.580
good API should consist of a shared
00:17:38.700
solution is the next step so we can turn
00:17:40.770
these best practices into conventions
00:17:44.330
for the last couple of months we've been
00:17:46.620
asking every developer we encounter what
00:17:48.510
they use to build a pis the answers were
00:17:51.300
usually rails or Sinatra with some
00:17:53.940
combination of its tools available on
00:17:55.920
Ruby toolbox and usually a partially
00:17:59.160
hand-rolled solution we also heard more
00:18:02.430
and more how rails is being used to
00:18:04.200
create a REST API that talks to a mobile
00:18:06.360
client and there seem to be growing
00:18:08.460
interest in using rails for JavaScript
00:18:10.320
frameworks these may not be traditional
00:18:12.990
rails applications but people still
00:18:15.060
recognize the value of rails for
00:18:16.830
creating a REST API after talking to
00:18:20.970
lots of people it was evident though
00:18:24.090
that in an agreed-upon solution still
00:18:26.430
wasn't clear and the whole thing just
00:18:28.230
required way too much thinking there's
00:18:31.470
so many ways to hobble something
00:18:33.210
together but we wanted to know the rails
00:18:34.980
wave what will be the rails way to build
00:18:37.140
a solid API again damnit rails if you're
00:18:39.960
so opinionated and committed to this
00:18:41.880
idea of conventions tell me what to do
00:18:44.070
we no longer have to be pioneers
00:18:45.750
venturing out into the unknown so in the
00:18:50.070
middle of all these conversations we did
00:18:52.710
see a rails way emerging though it's not
00:18:54.600
baked in yet lo and behold there are
00:18:57.540
solutions emerging from the core rails
00:18:59.130
team that provide an opinion on how to
00:19:01.290
create REST API s we've been exploring
00:19:03.960
rails API in combination with active
00:19:06.300
mile serializer for building an API
00:19:09.120
where you only need the JSON endpoints
00:19:12.090
rails API is rails utilizes most of the
00:19:16.050
same generators
00:19:17.200
conventions and will look very very
00:19:19.149
familiar for this new generation of
00:19:22.210
applications where the API is your
00:19:24.760
infrastructure that supports a family of
00:19:26.620
client applications we think this is
00:19:28.960
what the future might look like the
00:19:32.320
rails API is really just a miniature
00:19:34.539
rail stack where they've skipped all the
00:19:36.010
stuff that you need if you are creating
00:19:38.200
views producing a solution that is
00:19:41.049
lighter and faster than the full rails
00:19:42.429
app but it does still come with a full
00:19:44.710
suite of baked in solutions for many
00:19:47.740
poorly understood problems and the
00:19:51.220
documentation there's a laundry list of
00:19:52.840
things that are handled in the middle
00:19:54.130
welder layer and the action pack layer
00:19:56.320
this is definitely a win for example you
00:19:59.440
might understand perfectly how to
00:20:01.090
hand-roll a solution for IP spoofing
00:20:03.010
attacks or maybe that but even if you do
00:20:06.519
why spend time doing this is where else
00:20:07.990
is gonna do it for you thanks rails um
00:20:10.769
and again if there's a solution for
00:20:13.450
something already out there I'd rather
00:20:15.460
use that than reinvent the wheel the
00:20:18.899
other tool we're exploring is active
00:20:21.250
model serializers and short serializers
00:20:23.830
replace hash driven development with
00:20:25.779
object oriented development for example
00:20:29.200
with active model sterilizers when
00:20:30.549
you're using render json and your
00:20:32.019
controllers rails will search for a
00:20:34.299
serializer before for the object and use
00:20:36.850
it if available it's an elegant solution
00:20:39.370
to creating server side ap is that
00:20:42.070
doesn't require a view layer they act a
00:20:46.840
lot serializers acta lock like models
00:20:49.029
and can be easily customized actor model
00:20:51.429
serializers also follows the json api
00:20:54.370
standard so you know you're creating a
00:20:57.549
standardized api that will easily talk
00:20:59.620
to a variety appliance it really helps
00:21:04.029
to take the guessing out of how your
00:21:05.620
JSON API should be structured okay so
00:21:09.669
it's time to start wrapping things up a
00:21:12.429
few points to leave you leave everyone
00:21:14.830
with we find it's increasingly important
00:21:17.169
to design api's following patterns and
00:21:19.899
conventions that fit into the system as
00:21:22.840
a whole to do this we can leverage
00:21:24.820
existing best practices and tools and by
00:21:28.240
doing so will create a p.m.
00:21:29.770
is that support and more organized
00:21:31.210
structure for applications I was
00:21:34.480
inspired by yehuda katz as keynote
00:21:36.460
yesterday and I think it's time for us
00:21:39.070
as a community to move API design out of
00:21:41.950
the area of expert a shin and into the
00:21:44.890
area of our collective shared solution
00:21:47.770
will all benefit and again trivial
00:21:51.940
choices are the enemy drink your
00:21:54.850
convention over configuration kool-aid
00:21:56.860
but brush your teeth afterwards cool
00:21:59.500
aids not good for you um anyway we're
00:22:02.560
often trying to solve the same problem
00:22:05.230
and when this is the case we should
00:22:06.850
agree on a strong convention and I'll
00:22:08.950
follow it will all benefit in the end
00:22:11.800
and third and don't forget about who or
00:22:15.460
what else is going to want to use this
00:22:17.140
API in the future and plan accordingly
00:22:19.120
this may include native mobile
00:22:21.340
applications or a JavaScript client side
00:22:24.640
framework or something else that we
00:22:26.530
haven't even imagined yet by designing
00:22:28.960
our API is today to be consistent across
00:22:31.210
platforms we can make changes to our
00:22:33.280
client-side applications in the future
00:22:35.320
much easier so tomorrow someone's not
00:22:39.430
trying to use your hand rolled API that
00:22:41.140
didn't really follow any establish
00:22:43.090
design patterns or conventions and you
00:22:45.460
have to explain that well it seemed like
00:22:48.010
a good idea at the time for those of you
00:22:50.500
who aren't from Minneapolis this is the
00:22:52.030
ugliest building of the Minneapolis
00:22:53.410
guidelines this is how little context
00:22:56.140
for you oh we all drive by a shake our
00:22:59.080
heads like a lie or worse your
00:23:04.180
application gets scrapped because it was
00:23:06.010
poorly organized from the get-go and too
00:23:07.930
rigid to update oh and last but not
00:23:11.920
least document all the things
00:23:14.580
documentation is the key to your API
00:23:17.320
being used successfully all right and
00:23:21.430
we've come to the end um I hope just
00:23:25.000
want to leave you with one thought I
00:23:26.860
hope when you approach your next project
00:23:28.240
you'll consider building your API first
00:23:30.250
ah alright thanks everybody
00:23:53.470
you