►
From YouTube: The API flow - GitHub Satellite 2016
Description
Building an API takes more than coding a backend implementation. APIs are all about dialog. It takes culture, understanding, communication and collaboration to build a truly great API. The GitHub flow forms the backbone of the modern API-building process.
Zdenek “Z” Nemec is a computer systems researcher and architect. He is the author of the innovative API description language API Blueprint and also the author of the data modeling language MSON. He currently works at Apiary as the Director for domain specific languages, product manager and research lead for API design.
GitHub Satellite 2016 was a celebration of the latest and greatest in development. Watch the recordings to learn how engineers, founders, activists, and beyond tackle the latest and most difficult challenges in software.
For more, join us in San Francisco on September 13th-15th for GitHub Universe, three days filled with the creativity and curiosity of the largest software community in the world.
For more information, go to githubuniverse.com.
A
Thank
you
for
coming.
I
hope
you
are
enjoying
the
conference.
My
name
is
see
I
work
at
a
company,
it's
called
a
PRA.
What
we
do
at
a
PR
is
we
basically
create
tools
for
developers
for
people
who
are
developing,
designing
and
consuming
a
PRS
to
help
them.
You
know
doing
their
job
to
to
build
great
API,
and
today
I
would
like
to
talk
about
and
I
would
like
to
share
with
you.
A
What
I
have
learned
over
the
years
working
with
API
vendors
with
the
companies
who
are
no
developing
or
consuming
or
designing
api's
and
I
would
like
to
tell
you
told
you
about
the
you
know:
API
flow.
What
I
think
is
a
good
way
to
build
an
API,
and
hopefully
we
will
see
that
it
is
not
just
writing
a
server.
It
is
really
much
more
dangerous.
You
know
producing
a
code,
so,
let's
get
to
it
so
first,
how
did
we
get
here?
How
did
we
get
to
know
AP
is?
A
Is
anybody
of
you
hear
a
familiar
with
the
name?
Jcr
Licklider?
Does
anybody
know
this
person?
He
was
a
guy
in
the
60s,
really
a
grandfather
of
internet
and
one
of
the
enoki
person
in
in
the
ARPANET
evolution
and
what
we
now
have
and
what
we
now
know
as
the
internet,
and
he
back
in
the
60s
came
with
this
idea
in
this
paper.
He
was
talking
about
this
intergalactic
network.
A
A
Nobody,
yes,
well!
The
answer
is
very
simple:
they
would
have
to
figure
out
right
because
they
don't
know
each
other.
They
would
have
to
probe
each
other
and
sort
of
build
some
shared
understanding
and
you
know
build.
You
know,
understanding
what
that
other
entity
understands
and
then
used
shared
understanding
to
communicate
together.
A
Now
we
know
fast
forward
in
2016
we
have
this
intergalactic
network
of
computers
and
you
know,
distribute
the
networks
and
components
in
this
distributed
networks
and
the
question
is
the
same:
how
do
these
components
communicate
right?
Well,
the
answer
would
be
the
same:
they
would
have
to
figure
out
right
probe.
Each
other
establish
some
share
understanding
and
then
you
know
use
the
share
understanding
to
communicate.
Well,
we
figure
out.
A
Then
some
good
person
will
come
and
document
that
interface
right
a
lot
of
lot
of
documentations
right,
you
know,
explain
what
is
going
on
in
the
interface.
Then
somebody
else
will
come
read
the
thing
and
program,
another
component
that
uses
the
first
component
interface.
We
call
this
other
component
client
and
this
is
API,
so
what
it
really
is,
no
shirt
understanding
a
height
of
the
time
before
the
components
meet
each
other.
You
know
they
are
given
this.
You
know
God
like
knowledge
about
each
other.
A
They
are
not
figuring
now,
so
you
know
if
I
would
write
it
on
this.
Like
sort
of
flow
line,
I
would
say:
expose
the
interface
right,
the
dog,
with
the
dogs
program,
the
client,
I'm
pretty
sure
everybody
knows
that.
Well,
this
is
the
reality
right.
So
smart,
you
know,
person
exposes
the
interface,
then
a
unicorn
welcome
and
no
document
recommended
thing
and
then
somebody's
trying
to
use
it.
Probably
he
will
fail,
then
she
goes
back
and
read
the
documentation.
So
so
this
is
a
you
know.
A
This
is
AP
is
in
a
2016,
but
it's
really,
you
know
development
delivery,
consumption
and
then
hopefully,
some
analyzes
face
where
you
look
at
what
happened
and
you
iterate
the
gain
on
this
flow.
So
this
is
where
we
are
now,
and
this
is
a
lot
of
problems
right
like
first,
of
course
it
is
error
prone.
There
is
a
you
know,
so
much
human
work
involved
in
that
that
you
know
people
are
just
simply,
you
know
making
mistakes,
then
these
interfaces
or
this
components
of
distributed
systems
are
really
that
closely
together.
A
You
know,
because
you
are
sharing
something
ahead
of
a
time.
Good
luck!
You
know
changing
it
later,
so
you
know.
If
you
change
it,
you
get
a
broken
client.
If
you,
you
know,
if
you
want
to
change
it
in
some
way
that
you
don't
break
the
client,
you
are
coming
up
with
a
crazy
ideas:
how
to
version
the
thing
right.
Like
I'm
sure
you
guys
know
facebook,
facebook,
satellite,
alright,
we
are
not
going
to
change
the
shirt
understanding
for
two
years.
You
know
you
guys
can
be.
You
know.
Rest
assured,
programming,
clients
tie
them
together.
A
The
tank
won't
change.
Well,
you
know
it
prohibits
the
evolution.
You
probably
don't
want
to
live
in
that
world
next.
It
requires
a
couple
of
iterations
of
this
flow.
To
get
this
thing
right
because,
usually,
when
you
expose
an
interface,
the
clients
in
the
end
ends
up
using
it
in
a
very
you
know,
creative
and
different
way.
Then
you
have
expected
them
to
use
that
might
be
somewhere
fine,
but
sometimes
you
want
when
relative.
A
You
know
too
something
else
to
probably
iterate
couple
times
on
the
flow
you
know
to
get
to
the
interface
you
really
long.
Well
and
last
but
not
least,
it
doesn't
scale
right
back
to
the
you
know,
communicating
with
aliens
problem.
If
those
components
will
just
figure
out,
you
don't
need
to
know
humans,
writing
the
documentation
and
stuff.
You
know,
there'll
be
less
room
for
errors,
it
was
killed
and
infinitely
more
right.
A
Unfortunately,
until
we
have
the
components
that
are
smart
enough
to
figure
out
how
to
talk
to
each
other,
we
are
stuck
with
the
AP
is
but
good
news
is,
you
know
we
can.
You
know,
address
or
work
around
most
of
these
problems.
So
here
is
the
API
flow,
which
I
think
is
really
a
good
way
to
work
with
the
API
and
to
develop
an
API,
and
it
is
really
based
around
one
main
thing
and
the
main
thing
is
design
first
approach,
now
back
in
a
99
we're
a
ps4
new
thing.
A
You
know
they
were
sort
of
like
a
byproduct.
You
were
programming
or
developing
a
distributed
network,
a
distributed
system,
and
you
just
happen
to
need
an
API
there,
because
you
know
we
wanted
to
do
the
thing
distributed,
and
so
it
was
sort
of
a
byproduct
just
needed
an
API
and
interface
between
the
components
then
later
on.
People
has
realized
that
you
know
it
might
be
good
to
document
it.
Now
we
are
laser.
Programmers
right.
We
don't
like
to
you
know,
write
a
lot
of
documentation.
A
So
you
know
the
auto-generated
documentation
of
the
vertical
was
a
big
thing,
because
it
saves
me
the
work
right.
It
says
the
guy
who
is
documenting
the
API.
You
know
a
lot
of
four
well
guess
what
the
documentation
suffers
right
and
then
somebody
else
comes
later.
I
needs
to
understand
the
API,
so
really
your
API
is
only
as
good
as
its
documentation.
So
we
really
want
to
have
a
good
recommendation.
A
Now
we
are
finally
in
2016
getting
to
a
situation
where
you
know
API
are
twisted
as
a
product
and
and
they
are
designed
first,
you
know
so
you
first
think
about
your
API
before
you
start,
you
know
doing
you
know
development
and
consumption
of
the
API.
So
the
thing
the
important
thing
here
really
is
like,
if
you
think,
of
an
EP
API
as
a
product,
you
should
really
treat
it
as
one.
So
you
know
we
develop
software.
We
know
how
to
treat
it.
We
do.
You
know
research
designs
with
the
prototypes.
A
The
same
applies
to
a
parent.
It
is
really
a
product,
so
I'm
grading.
The
flow
is
in
before
I
just
put
their
the
design
phase
at
the
front.
It's
still
a
linear,
linear,
linear
flow
and
I
would
even
argue
that
there
is
something
like
a
preparation
that
needs
to
be
done
before
you
start
designing
API
and
if
you
did
it,
you
can
significantly
improve
developer
experience
both
within
your
company
and
you
know,
with
with
Europeans
users,
but
this
is
a
still
a
waterfall
right.
A
If
you
design
something
at
the
star,
you
have
to
go
through
all
these
steps
and
I
learn
at
the
very
end
after
you
know,
some
consumers
and
clients
will
actually
use
it.
Yes,
you
will
learn
at
the
very
end.
You
know
that
there
were
some
mistakes.
There
need
to
be
some
changes
done
today
behind.
So
how
can
we
fix
this?
A
My
suggestion
here
is
to
prototype
very
quickly,
and
actually
you
know
you
can
prototype
in
a
design
phase.
So
at
the
very
moment,
when
you
have
your
design
a
very
pure,
like
you're
sort
of
blueprint
of
what
do
you
think
you
want
to
build,
you
can
already
get
a
prototype,
a
step
implementation
of
the
API,
and
you
want
to
play
with
it
and
since
you
have
it,
you
can
skip.
A
You
know
the
development
and
delivery
fish,
and
if
you
have
a
stop
implementation
of
very
p
I,
you
can
start
writing
a
client
at
the
same
time.
Ideally,
you
want
to
do
both
at
the
same
time
like
development
of
the
backend
and
development
of
the
client.
Right
now
you
know
in
2016
and
design
first
approach.
You
can
really
do
this.
Just
design
your
FB
I
use
a
stop.
Stop
implementation
without
writing
any
code.
Maybe
you
will
never
write.
We
will
never
write
the
you
know:
server
server,
back-end!
A
You
will
just
write
the
client
and
you'll
figure
out
that
it's
all
wrong,
and
so-
and
that
comes
to
my
next
point-
that
you
really
want
to
analyze
in
every
of
those
faces
and
analyze.
You
know:
go
back
to
design
reflect
that
in
this
design
phase.
So
this
would
be
a
sort
of
flow
and
faces
of
the
flow.
In
a
nutshell:
it's
no
longer
wonderful,
you
are,
you
know,
free
to
sort
of
modify
and
improve
your
designs,
your
API
designs
and
really
move
faster.
A
A
First
now,
every
of
these
phases
consists
of
several
steps
and
let's
look
in
these
steps
in
the
details
the
first
base,
the
preparation
is
actually
the
one
most
underestimated
faces,
I
ever
seen
in
API
development,
and
it
starts
with
the
more
I
think
the
most
important
step
and
that's
the
definition
of
a
domain
semantics.
What
things
are
is
this
a
chair
is
this:
a
chair
is
this
a
chair.
Well,
I
could
definitely
consider
this
right,
but
you
need
to
in
your
organization,
with
your
clients,
have
a
shirt
understanding
of
what
the
things
are
right.
A
How
do
I
name
things
like
you
might
be
like?
Oh,
this
is
very
simple.
Everybody
knows
what
chair
is
right.
This
is
not
the
chair.
Well,
maybe
for
somebody
it
is
right
and
you
just
want
to
make
sure
that
you
know
you
are
on
the
same
page
here.
I
have
a
guy
from
a
big
American
news
corporation.
They
have
a
he's,
an
architect
of
an
AP.
Is
there.
They
ran
a
lot
of
lot
of
departments
from
the
news
from
TV
studios
to
online
media
and
he's
like,
oh
so
one
organization
or
11
team.
A
You
know
they
call
this
thing.
The
article,
the
other
team,
calls
it
the
copy.
The
other
team
causes
the
blog
post.
You
know
in
the
end,
those
are
maybe
the
same
things.
What
is
the
outer?
What
is
the
person
you
know?
What
are
the
attributes,
this
sort
of
kind
of
things
in
your
application?
You
know,
whatever
is
your
domain
I'm,
pretty
sure?
A
If
you
grab
your
people,
sit
together
and
start
trying
to
name
things,
you
will
find
out
very
soon
that
will
be
arguing
what
the
thing
is
and
what
a
thing
isn't
so
make
sure
you
are
on
the
same
page
with
everybody
when
you
are
building
your
API
next,
also
very
ignored,
step
step,
architectural
style.
Well,
today,
everybody
is
talking
about
rest
right.
It's
easy!
We
do
a
REST
API.
The
truth
is,
nobody
is
doing
REST
API
as
a
Roy
fielding
in
99
projected
it.
A
Everybody
is
doing
some
flavor
of
it
or
maybe
some
very
different
thing,
and
that
is
ok.
You
don't
have
to
do.
Rest
rest,
you
know,
might
work
for
you,
my
note.
What
is
not.
Ok
is
choosing
a
architectural
style
and
ignoring
its
drawbacks
and
not
understanding
the
other
architectural
styles.
So
make
sure
you
know
what
is
the
right
style
for
your
for
application
domain
again
there
is
no
solar
bullet.
There
is
a
good
style
for
that
and
another
stone
might
be
appropriate
for
some
something
very
different.
A
So
you
know
if
your
API
is
just
one
of
thing
for
I,
don't
know
an
event
that
lasts
for
just
one
day
or
you
know
your
API
should
last
for
years
there
are
different
architectural
styles.
You
probably
want
to
know
employee
one
might
take
a
long
time
to
develop,
but
it
will
be
pretty
robust.
The
other
will
be
right
there,
but
you
know
good
luck,
changing
it
in
a
month
right
and
things
like
this,
so
pick
the
right
style
and
make
sure
everybody
understands
the
style.
A
A
The
last
step
in
the
preparation
phase
is
a
formalization
of
the
style
guide
and
you
can
think
of
this
as
a
sort
of
coding
standard
coding,
standards
of
API.
So
this
is
where
you
say
how
you
will
name
your
resources
named
Yuri,
what
urls
come
a
case
lower
case.
This
is
where
you
say:
how
do
you
do
pagination?
How
do
you
do
aunt
indication
right
and
you
will
reuse
this?
You
will
write
it
down
and
use
this
definition,
because
you,
probably
if
you
have
a
more
is
you
want
to
use
the
same
pagination
style?
A
If
you
don't
well
the
consistency
and
the
developers,
experience
will
suffer.
So
that's
a
preparation,
phase,
very
important
one.
Most
of
fun
ignore
design
prototype
so
I'm,
still
not
even
getting
to
designing
your
API
I
didn't
even
get
to
building
api's
right
identification
of
your
resources.
You
have
a
you
have
this.
You
know
list
of
terms
the
semantics
of
your
domain.
Whatever
you
have
there
it's
yours
now
you
want
to
look
at
that
and
think
about
what
are
the
resources?
What
am
I
going
to
expose?
What
are
just
some
attributes?
What
are
some
data?
A
A
It
is
a
finite
state
machine.
It
is
a
state
machine
diagram
and
as
scary
as
it
is,
it's
very
cool
thing
when
you
are
designing
an
API.
This
one
shows
a
message
resource
and
it's
saying
it
has
a
three-state.
A
message
can
be
drafted,
it
can
be
sent
and
it
can
be
archived
right.
But
it's
really
interesting
here
is
that
in
each
state
the
resource
affords
with
different
actions
right.
A
drafted
message
can
be
edited.
A
It
affords
you
to
edit
the
message
once
the
you
sent
the
message
you
are
in
the
same
state,
you
can
no
longer
edit
it.
So
this
is
a
state
machine
of
one
resource,
and
if
you
draw
this,
you
will
have
a
very
clear
understanding
of
what
that
resources.
What
are
the
attributes?
What
are
the
actions
at
the
fort,
and
it
will
help
you,
furthermore,
to
understand
the
relations
between
the
resources
like
this
is
a
message
this
is
its
outer,
you
know
outer
has
I,
don't
know
and
etcetera,
etc.
So
you
know
look
at
this.
A
Financing
machine
is
really
a
very
helpful
thing
when
you
start
to
think
about
your
API
now
the
first
real
work.
You
know
the
first
after
thinking
you
want
to
formalize
all
this
steps,
we've
done
so
far,
so
we
want
to
write
it
down.
Now
we
have
a
couple
of
API
description,
languages
I'm,
an
author
of
one,
wonder
it,
but
there
there
is
many
of
them.
So
again
pick
the
right
one
for
you,
the
one
you
like
and
use
it
now.
I
have
an
email
there,
and
this
is
a
story.
A
Five
years
ago,
I
was
doing
a
cool
application.
I
was
a
front
end
guy
doing
an
iOS
app
and
my
friend
Paul
he
was
a
server
guy
and
I
was
sending
him
emails
like
this.
Like
hey
Paul,
can
we,
you
know,
do
an
API
that
will
do
this
in
debt
and
debt
and
he
replied
me
back
yeah.
But
what
about
you
know
this
response,
doing
that
and
I
said
sure,
but
about
this,
and
we
were
back
and
forth
back
and
forth.
I,
don't
know
if
this
has
happened
to.
A
It
happened
to
me
three
days
later
for
the
image
later
riri
riri
right.
Like
good
luck,
we
did
an
API
design
over
the
emails.
Good
luck
figuring
it
out.
What
we
settled,
then,
in
three
days
right,
like
reading
all
those
innocent
trying
to
make
a
mental
picture
of
what
the
API
should
be.
So
please
use
one
of
the
API
description
formats.
It
will
really
help
you
to
you,
know,
get
this
right
and
obviously
using
a
github
data
flow.
A
Helps
you
there,
because
you
have
a
version
control
and
you
see
the
directions
you
can
discuss
it
there
now,
once
you
have
the
description
formalized
once
you
have
the
design
from
life
in
API
description
for
man,
you
can
take
the
shortcut
I
was
talking
about.
There
is
a
couple
of
a
mock
servers,
so
you
just
take
this
description,
you
throw
it
in
the
internet
little
program
and
it
will
spins
up
basically
stuff
implementation
of
your
API
right.
A
So
you
don't
need
to
write
any
code
and
you
can
just
experiment
with
it
from
the
command
line
from
wherever
you
want.
You
can
start
writing
a
real
client
like
we
had
a
PR.
We
provide
your
hosted
mock
server,
so
we
just
write
the
description
and
there
is
already
your
you
know:
dummy
implementation
somewhere
in
the
clown.
So
you
can
take
a
shortcut
from
here:
go
all
the
way
to
the
consumption
face
and
start
working
on
your
client
again.
This
is
really
moving
the
first
moment
of
truth.
A
Finally,
for
the
design
phase
share
any
of
you,
the
thing
and
I
have
to
really
stop
and
zoom
on
this
one
a
little
bit,
because
this
that's
what
you
know
makes
a
good
design,
really
good
design
sharing
and
reviewing,
and
that's
really
the
big
difference
between
the
you
know
the
classical
flow
we
had
there
at
the
start
and
I
will
actually
talk
a
little
bit
about
the
github
flow.
I
hope
you
guys
are
familiar
with
it
and
it's
not
really
the
sequence
of
steps
I
like
about
the
github
flow.
A
It's
not
that
you
create
a
brand.
You
do
some
comments.
You
do
put
request.
What
I
laugh
about
the
github
flow
is
the
fact
that
it
gives
you
clear
point
in
the
life
cycle
of
a
software
where
people
interact
with
each
other,
in
other
words
where
they
collaborate.
It
gives
you
clear
checkpoints
where
different
personas
are
different
doing
things
and
when
they
are
engaged
when
they
are
doing
code
reviews
when
they
are
talking
together
and
they
are
programming,
that's
the
best
thing
about
the
github
move.
To
me.
A
You
know
it
clearly
says
how
people
collaborate
together
so
back
to
api's.
You
really
want
to
involve
everybody
in
the
design
process.
It
won't
be
surprised
if
I
tell
you
that
you
know
the
best.
Api's
are
those
that
are
understood
right,
regardless
of
a
style
or
what
they
are
above,
like
you
know,
really
get
everybody
there.
So
this
would
be
the
difference.
You
know
there.
You
had
those
people
in
the
silos
not
really
talking
about
each
other.
But
what
I'm
saying
here
is
like
get
everybody.
A
You
know
to
design
a
prototype
and
you
know
get
them
agree
on
the
on
the
design
you
have
made.
So
that's
essentially
a
contract.
Once
you
get
everybody
agreeing
on
the
contract,
you
know
you
said
this
is
an
API
I'm
going
to
build.
This
is
an
API
I
want
to
consume
a
product
owner,
say
all
right.
I
want
really
to
build
this
I'm
committing
my
resources
to
date
and
the
decorator
guys,
like
you
understand
that
I
can
document
it.
You
can
treat
it
really
as
a
contract
between
everybody
involved
with
the
API.
A
So
this
shirt
understanding
in
this
you
know,
intergalactic
network
becomes
the
contract
between
all
the
parties
involved
and
because
it
is
a
contract,
I
really
suggest
to
put
it
on
a
github
in
the
same
repo
as
you
have
the
implementation.
So
we
have
the
code
with
your
own
back-end
implementation
and
next
to
it,
you
have
this
contract
and
what
you
really
want
to
do
is
keep
checking.
As
you
are
developing
the
server
you
want
to
keep
checking
that
the
thing
is
according
to
the
contract,
so
one
thing
you
can
do
is
test
it
locally.
A
We
have
built
a
tool,
it's
called
red
and
it
brings
justice
to
your
API
development
and
what
it
really
does
it
spins.
When
you
run
it
locally
on
your
local
computer,
it
spins
up
the
instance
of
your
server.
It
takes
the
description,
exercise
every
single
thing
in
the
description
and
reports
and
discrepancies
from
the
actual
server.
So
you
can
sort
of
even
think
of
it
as
a
test
driven
development
right,
you
are
when
you
are
starting,
nothing
is
implemented.
A
All
the
tests
are
read
right
once
you
know
you
are
starting
adding
this
endpoint
that
are
written
in
this
contract.
The
tank
will
get
win
green
winner
until
I
the
screen
right
now
we
are
good
guys
here,
so
we
use
a
CI,
so
we
just
the
same
thing,
will
do
in
a
continuous
integration
and
again
the
cool
thing
here
is
you
have
a
contract,
the
tests
and
the
implementation
and
some
repo?
If
you
push
the
change
to
implementation
it
get
tested.
If
you
push
the
change
to
the
contract
it
gets
tested,
you
always
know.
A
A
If
you,
you
know,
have
the
Mach
using
the
very
same
contract
from
the
very
same
repo.
The
mock
is
always
up
today
same
for
the
other
tools.
I
will
be
talking
shortly.
So
the
point
here
is
really:
you
have
a
single
place
single
in
no
place
for
truth
about
your
api
contract.
Everybody
agrees
to
pawn
using
the
github
flow,
it's
sitting
legal
help,
and
you
know
every
time
you
change
it.
Everything
gets
updated.
If
the
test
fails,
you
know,
you
know
the
documentation
is
updated
or
it
is
not
updated.
A
Basically,
based
on
you
know
whether
it
will
deploy
the
implementation
or
not.
So
you
are
assured
all
these
things
are
insane
so
back
to
development,
always
leaving
this
tested
deployed.
There
is
a
parallel
thought
right
now,
in
the
other
room
where
good
maunder
is
discussing
the
Heroku
flow,
so
you
probably
want
to
watch
it
as
well.
I
do
want
to
watch
it
so
deploy
your
server
pray,
pretty
clear
delivery
delivery
face.
You
just
share
your
API
description.
That
is
really
all
about
matters
or
you
can
hands
out
the
documentation
rendered
out
of
the
description.
A
Usually
the
documentation
has
some.
You
know
nice
buzz
and
baseless
interactivity
in
it
like
a
language
examples
or
console
or
whatnot,
but
it's
really
again
rendered
version
of
the
API
description.
Finally,
a
good
you
know
very
important
thing
from
the
delivery
face
is
a
pain
management.
Some
of
the
api's
do
not
need
it,
some
of
them
do.
If
you
have
a
lot
of
users,
you
have
to
manage
the
tokens.
You
know
users
of
your
application.
I
held
this.
A
A
However,
you
can
experiment
and
you
should
experiment
with
the
API
before
you
start
using
it
and,
of
course
you
can
use
this
URL
or
poor
or
our
postman,
but
I
would
suggest
you
will
use
basically
a
client
tool
like
shown
here.
That
is
aware
of
the
contract,
because
what
you
see
here,
I'm,
not
sure
we
can
read
it,
but
basically
I'm
doing
a
post
request
to
an
end
point
and
I
have
forget
to
add
a
content
type
header
in
the
request
body.
A
This
thing
is
telling
me
that
I,
you
know
I
have
something
missing
in
my
request
and
this
thing
knows
it
because
it
knows
it's
from
the
contract.
It
knows
it
from
the
shared
understanding.
We
shared
a
head
of
a
time.
It
knows
that
I
as
a
client
was,
you
know,
was
supposed
to
send
the
content-type
header,
so
it
will
help
you
as
a
client
developer,
to
see
what
you
are
actually
sending
and
what
you
are
maybe
missing
from
what
was
agreed
upon.
A
Finally,
then
I
like
this
place,
I'll
be
very
brief
here,
but
it's
very
important,
you
know
just
get
all
the
feedback
both
from
the
actual
people
who
are
in
those
faces.
You
know
developers,
clients,
obviously
even
decorator,
can
have
like
very
valuable
feedback.
So
listen
to
these
people
and
also
you
know,
have
some
measurement
in
your
application
very,
very
easily.
You
can
find
out
that
some,
you
know,
endpoints
are
not
used
or
some
other
endpoints
are
abused
and
you
can
probably
you
know
others
that
later
when
you
iterate
on
this
API
flow.
A
So
this
is
what
I
think
that
is
a
good
way
to
build
api's,
as
you
could
see,
you
know,
taking
the
server
somewhere
in
the
middle
reading.
Something
except
of
a
lot
of
text
is
here.
So
you
know,
building
an
API
is
really
more
conceptual
work
than
the
natural
coding
and
the
more
time
you
spend
with
the
preparation
with
this
design
and
the
more
people
have
involved
there.
A
You
know
the
better
API
you
are
going
to
gain,
and
now
this
was
a
lot
of
information,
so
I
have
put
together
on
this
little
side
where
it's
basically
all
look
things.
I
was
talking
about
with
a
greater
detail:
it's
a
hosted
at
a
PR
e
io
how
to
build
api.
We
are
just
launching
it
right
now,
so
you
are
the
very
first
one
to
know
about
this.
It's
basically
going
through
all
these
steps
with
a
lot
of
detail
and
yeah,
so
you
know
look
at
it.