►
Description
APIdays San Francisco 2019
Opening Keynote
Uri Sarid, CTO Mulesoft
Speakers slides from the conference:
https://www.slideshare.net/APIdays_official
Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io/
Explore the API ecosystem with the API Landscape:
https://www.apiscene.io/api-landscape/
Deep dive into the API industry with our reports:
https://www.apidays.co/industry-reports
Subscribe to our global newsletter:
https://apidays.typeform.com/to/i1MPEW
A
What's
the
only
explanation,
I
have
for
this
title,
so
you're
gonna
hear
incredible
amount
of
interesting
technology
in
these
days,
not
just
about
api's
and
api
specs,
but
API
implementations
and
service
meshes
and
API
security,
and
really
really
interesting.
Topics
that
are
happening.
I
actually
wanted
to
start
us
off
with
a
little
bit
of
an
introspection
just
for
a
moment.
Ask
ourselves
Oh,
safe
harbor.
That's
the
thing
that
flew
by
ask
ourselves.
Why
are
we
here?
What
actually
brought
us
to
this
place
today?
Think
for
yourself?
Why
are
you
here
personally?
A
What
what
is
it
about?
Api's,
that's
worth
throwing
a
conference
about.
Why
is
it
that
everybody
in
the
world
is
talking
about
api's
and
by
everybody?
I,
don't
just
mean
technologists,
I
mean
like
BBC.
Why
is
everybody
talking
about
api's?
What
is
the
thing
that
makes
that
happen?
Why
are
we
so
excited
about
it
and
what
do
we
as
thought,
leaders
and
as
path
favors
need
to
keep
in
mind
so
that
this
momentum
that
we're
all
benefiting
from
and
enjoying
actually
sustains
and,
in
fact,
goes
faster?
A
That's
what
I
wanted
to
talk
here
about
versus
all
of
the
technologies,
and
so
on
that
you
will
hear
in
in
the
rest
of
this
conference
in
the
next
couple
of
days.
So
the
first
question
is
or
the
first
question
is:
what
brings
us
personally
here
and
I
would
vouch
that
most
people
are
here
because
we
love
tools.
We
love
to
build
things.
We
like
to
assemble,
there's
something
inherent
it's
it's.
A
Arguably,
everything
that
we
do
in
the
world
today
could
be
done
by
people
manually,
but
the
whole
point
for
hundreds
and
now
tens
of
years
in
the
API
world
is
to
automate
right.
Let's
just
keep
that
in
mind.
Okay,
now,
why
is
the
business
so
interested
in
it
right?
Who
is
funding
all
of
this
thing?
Why
is
this
actually
changing
the
way
that
businesses,
work
and
I
would
argue
that
the
first
thing
is
leverage
right.
A
A
This
API
economy
so
with
that
said,
there's
an
interesting
aspect
that
we
often
lose
track
of
when
we
talk
about
in
general,
sort
of
API
economy
and
open,
api's
and
and
sort
of
programmable
web,
and
all
of
that,
which
is
that
this
is
fueling
a
revolution
inside
of
companies
as
much
as
outside
of
companies
so
inside
of
a
company.
What
you'll
often
want
is
you
want?
You
want
cost-savings
right,
you'll
want
to
go
faster.
A
You
want
to
deliver
innovations
faster
and
the
mechanism
that
companies
are
doing
this
increasingly,
as
they
say,
I've
got
a
bunch
of
a
pis
and
I've
got
a
bunch
of
back-end
systems
that
I
put
api's
on
top
of
and
I
hook
them
up
together,
but
I
end
up
producing
new
api's
and
I
check
that
into
serve
an
app
store
and
in
that
world.
I've
got
capabilities
that
I
built
for
the
last
project.
A
Just
like
you
have
a
computer
network
where
all
the
pieces
are
interoperable.
So,
at
the
application
level,
all
these
capabilities
become
interoperable
because
there's
API
is
in
front
of
them.
You
can
discover
and
you
can
consume
and
so
on.
That
concept
is
something
that
we're
starting
to
see
now,
not
just
inside
of
companies,
but
as
companies
start
to
work
with
each
other.
You
start
to
see
these
application
networks
converge,
that's
not
a
surprise
right,
they
will
often
use
the
same
services
or
they
will
partner
with
each
other.
A
If
you're
in
the
enterprise
space,
two
of
your
customers
are
probably
already
working
with
each
other.
So
in
that
way,
these
application
networks
start
to
converge
and
we
can
start
to
see
the
beginnings
of
really
a
new
global
architecture.
Not
just
API
is
in
terms
of
economy,
but
an
architecture
that
is
collaborative
that
is
competitive.
That
evolves
very,
very
quickly.
That
is,
merit
oriented
just
what
we'd
want
to
do
for
a
distributed.
Architecture
mirror
is
very
much
the
web,
but
at
the
API
functional
level
at
the
automation
level.
A
A
You've
got
some
issue
coming
up
and
that
should
be
able
to
then
align
with
both
your
calendar
and
the
calendar
of
say,
local
medical
providers
to
say,
hey,
there's
a
doctor
that
can
actually
see,
and
when
that
happens,
you
should
be
able
to
then
align
with
a
rideshare
API
that
will
book
you.
The
trip
to
actually
get
to
your
doctor,
and
when
you
get
to
your
doctor,
all
of
the
API
is
in
front
of
medical
records,
should
align
and
bring
a
unified
view.
Basically,
to
the
doctor
shows
you
a
patient
360.
A
You
should
see
all
of
your
information
as
the
doctor
is
now
very
efficiently
and
correctly
prescribed
something
for
you
and
you
head
back.
Your
prescription
is
being
sent
over
to
a
local
pharmacy
and
that
pharmacy
should
be
able
to
check
that
against
again
your
medical
records
exposed
through
those
api's
and
say
hey.
This
is
the
right
thing
to
actually
dispense
to
you
and
there's
no
reason.
They
can't
then
keep
going
with
that
API
for
couriers
and
deliver
that
medication
straight
to
your
office.
A
They
know
exactly
where
it
is
that
you
live
so
that
within
two
hours
of
not
feeling
good,
you're
already
administering
the
medication,
that's
a
coherence
along
these
directions.
That's
really
only
enabled
by
api's
right
to
do
this
manually
would
be
prohibitive,
but
we
can
automate
that
and
the
cost
to
do
this
is
arguably
no
bigger
than
the
regular
cost
to
to
do
any
service.
A
And
if
that's
true
that
changes
the
economy,
there's
something
called
the
coherence
economy,
I
think
it's
going
to
start
emerging
where
once
consumers
get
used
to
this,
they
never
go
back
and
businesses
have
to
now
serve
things
at
this
level
and
that's
what
ends
up
changing
the
economy.
So
I'm
going
to
leave
this
as
a
thought
to
you
and
go
back
to
what
part
two
API
is
actually
play
in
all
of
this.
So
we
have
tended
over
the
last
few
years
to
talk
about
api's
as
products
right
and
that's
really
what
the
business
understands.
A
That's,
arguably,
what
we
should
all
be
thinking
about
with
respect
to
API
is
because
we
are
serving
our
consumers.
Our
consumers
might
be
the
team
next
door
because
we're
doing
micro
services,
but
there's
still
a
consumer
in
mind,
and
so,
if
you're
thinking
about
your
API
is
as
products
with
a
consumer
orientation
you're
making
sure
that
the
API
capability
behind
the
API
really
is
valuable,
you're,
making
sure
that
it's
reliable,
so
people
can
actually
build.
On
top
of
this
thing,
remember
all
of
this
is
actually
behind
the
API.
A
The
API
is
in
service
of
something
bigger,
and
the
third
thing
is
it's
actually
a
delightful
consumption
experience,
because
it's
so
painful
to
consume
yours
they'll,
probably
go
and
find
something
else
to
do.
Okay,
so
we're
all
used
to
thinking
about
that
in
the
last
few
years.
I
would
argue
we
should
be.
We
should
lean
in
more.
We
should
think
harder
about
this
and
go
for
something.
That's
a
little
bit
more
prescriptive
than
this.
We
should
be
thinking
as
productized
building
blocks,
because
we
know
better.
We
know
that
those
api's
don't
stand
alone.
A
We
know
that
they're
weaving
together
and
we
know
that
one
stands
at
the
top
of
another.
So
if
you
were
to
look
at
it
in
this
way,
you
would
use
three
different
words
over
there.
First
is
it's
got
to
be
simple.
It's
got
to
be
the
kind
of
thing
where,
if
you're
looking
to
assemble
something,
it's
pretty
clear
to
you
that
this
is
actually
simple
thing
that
it's
utilitarian.
It
actually
serves
a
purpose.
A
So
I've
chosen
a
domain,
an
area
that
I
think
everybody
understands
I,
don't
need
to
explain
how
banking
works,
I
don't
have
to
go
into
insurance
or
healthcare,
or
so
on.
Everybody's
done
commerce,
and
in
fact,
even
though
I'll
be
talking
in
the
language
of
e-commerce.
These
concepts
have
not
changed
for
several
thousand
years.
A
The
Babylonians
would
probably
recognize
most
of
this
stuff,
at
least
at
this
level,
so
I'm
going
to
talk
about
the
domain
model
of
e-commerce
as
an
example
here
and
focus
first
on
the
semantics
fancy
word
to
just
say:
let's
agree
on
what
we're
talking
about.
That's
actually
really
really
key
a
lot
of
us
love
to
jump
towards
execution,
but
if
we
can
start
by
just
agreeing
and
what
the
actual
concepts
are
you
preserve
that
utilitarian
aspect
all
throughout.
So
let's
talk
about
that
first
concept:
in
order
an
order
has
a
recipient
name,
a
recipient
email.
A
An
order
is
a
business
transaction
that
has
happened
very
straightforward.
If
you
were
to
pop
it
open,
there
would
be
a
lot
more
fields
inside,
but
it's
really
important
to
establish
the
notion
of
an
order
and
when
I
say
establish
it's
not
just
the
box,
it's
actually
a
file
which
you
can't
read
here,
probably
but
trust
me
that
there
are
properties
inside
of
that
order.
That
correspond
exactly
to
these
things
and
the
point
about
being
a
file
is
that
there
is
data
here.
Okay,
it's
metadata,
but
it's
still
data.
You
can
store
it
somewhere.
A
You
can
put
it
in
fact
in
a
graph
database
and
go
and
query
what's
inside
of
that,
so
we're
treating
very
technically
this
notion
of
a
domain
model
and
I'll
get
back
to
that
in
a
little
bit.
So
I
had
an
order,
then
an
order
item
there's
a
relation
between
them,
nothing
particular
special
and
very
quickly.
I,
say:
surely
somebody
has
done
this
before,
maybe
not
the
Babylonians,
but
somebody
else
must
have
already
done
something
like
this
before.
Why
do
I
have
to
invent
all
of
these
semantics?
A
Arguably,
if
I
can
find
a
bunch
of
semantics
that
everybody
already
agrees
on,
I
can
align
with
that.
I
can
save
myself
work
and
everybody
in
my
business
can
be
talking
about
exactly
the
same
thing.
So
I
go
to
one
such
place
inside
the
sales
domain,
I'm
gonna
import
stuff
from
a
place
that
I
already
captured
all
of
these
semantics.
If
you
go
to
schema.org,
it's
already
got
all
of
this
stuff
in
there.
So
why
don't
I
just
borrow
from
that
borrowing
by
the
way
is
a
good
thing.
A
It's
not
something
you
have
to
ask
for.
Apologies
for
right!
Borrowing
is
actually
really
really
good,
so
I'm
gonna
go
to
schema.org
and
discover
wow
they've
thought
through
all
this
stuff.
Okay,
so
I'm,
just
gonna
pull
in
some
of
these
things
from
schema.org
I've
got
an
offer,
which
is
technically
the
thing
that
you
actually
do.
When
you
say
to
somebody,
you
can
buy
something
in
fact:
I've
modeled,
warranty
and
there's
more
and
more
things
there.
So
I'm
like
at
a
party
here,
I'm,
just
borrowing
more
and
more
stuff.
A
A
There's
the
products
in
the
inventories
and
on
the
other
side,
there's
how
do
I
get
it
to
you
and
postal
addresses
all
of
that
I
just
slurp
right
in
because
now
I
have
a
general
like
effectively
a
universal
domain
model
to
describe
those
things
that
are
gonna
eventually
come
up
as
api's.
So
I
start
with
that
and
I
need
to
zoom
out
a
little
bit.
You'll
see
why
a
little
bit
later,
the
thing
just
gets
big
so
think
about
all
of
these
as
business
entities
right.
A
Here's,
the
organization
and
the
party
inside
of
this
kind
of
a
party
folder.
If
you
like,
the
commercial
transaction
and
so
I've
modeled,
my
domain
I've
established
what
it
is
that
I'm
talking
about-
and
this
is
something
that
businesspeople
and
technical
people
can
actually
agree
on
and
remember.
It's
all
technical
and
as
I
go
through.
I
will
now
be
creating
data.
A
And
we're
back
across
all
of
these
domains.
Okay,
so
this
is
a
really
important
exercise
again.
It
may
feel
like
this
is
just
philosophy
or
what
Enterprise
architects
do,
but
the
reality
is
that
establishing
early
on
what
it
is
that
we
mean
will
stop
the
misunderstandings
before
they
make
it
down
into
the
service
mission.
It's
pretty
hard
to
fix.
Okay!
A
A
But
this
is
the
technical
domain.
I
may
need
to
actually
add
some
new
properties
to
it
for
technical
reasons
and
these
other
things
that
were
in
my
domain
model
actually
get
embedded
inside
these
schemas.
So
it's
not
a
one-to-one.
In
fact,
there
will
be
lots
of
variations
of
these
schemas
for
different
people.
That's
okay!
We're
not
trying
to
be
canonical
about
the
schemas!
We
are
trying
to
be
canonical
about
the
domain
model.
A
The
meaning
of
these
things
and
I
need
to
add
a
little
bit
more,
so
I
take
in
a
payment
from
another
place
and
then
I
add
a
couple
of
things
that
don't
exist
in
my
domain
model
at
all,
but
are
necessary
for
business
processes.
So
I
need
to
know
what
a
shopping
cart
actually
looks
like
in
terms
of
data
and
when
you're
actually
doing
a
checkout,
which
is
an
intermediate
state.
I
need
to
capture
that
as
well.
A
So
that's
the
relationship
between
the
domain
model
and
the
and
the
actual
schemas
and
we'll
do
a
lot
with
our
schemas
and
there's
relationships
between
them
and
so
on.
I
won't
bore
you
with
the
details,
hopefully
you're
getting
the
gist
of
this
thing.
So
I've
got
my
domain
model.
I've
got
my
data
model
and
by
the
way,
data
is
a
great
way
to
talk
to
the
business
right.
They'll
understand
the
data
aspect.
They
may
not
know
the
internals
of
api's,
but
they
certainly
can
talk.
A
Data
and
now
I
need
to
figure
out
what
am
I
going
to
do
for
the
API
and
there
I
have
a
choice.
So
there's
lots
of
things
and
we'll
see
in
this
conference.
There's
lots
of
ways
to
actually
go
to
the
next
step.
I'm
gonna
start
with
one
that
you
actually
see
very
often,
which
is
hey.
I've
got
my
data.
I
know,
I'm
gonna
talk
over
HTTP.
A
What
do
I
do
the
one
way
to
do
that
Java,
so
I
take
the
schemas
that
I
had
before
I
generate
the
Java
representation
of
schema
in
this
case
pojos
and
now
I
need
to
start
wiring
the
stuff
up
together
and
adding
the
capabilities
to
this
thing.
So
I'm
gonna
add
here
a
post,
the
ability
to
create
something
new
and
then
I'm
gonna,
add
I,
get
to
be
able
to
get
the
thing
that
I
added
I'm
going
through
this
faster.
A
You
don't
try
to
read
this
and
I
put
so
you
can
modify
it
and
yeah
if
it
looks
like
there's
a
lot
of
work
here,
there's
a
lot
of
work
here
right,
not
nearly
as
much
work
as
having
to
literally
code
everything
in
assembler
or
something,
but
it's
certainly
a
lot
of
work.
Having
said
that,
this
is
what
you
need
to
do.
A
If
you're
gonna
just
manually
create
an
API
part
of
the
data
schema
that
we
already
have
once
you
have
this,
though
you're
in
pretty
good
shape,
because
you
could
generate
an
API
specification
now,
this
will
become
a
contract
with
your
consumers.
This
is
super
important.
I
know
we're
gonna
talk
a
lot
more
about
this.
This
one
is
an
open
API.
It
captures
all
of
that
API
that
we
just
modeled
out
in
code
and
once
you
have
an
API
spec,
that's
great
now
you
can
generate
UI.
Out
of
this
thing,
you
can
generate
SDKs.
A
Out
of
this
thing,
you
can
create
a
portal.
You
get
a
lot
of
advantages
once
you've
gotten
to
that
step.
You
say
you
don't
want
to
do
it
this
way.
You
want
to
use
graph
QL
great
same
idea
and
again
we're
gonna
hear
more
about
this.
In
a
little
bit
in
graph
QL
again
I
effectively
generate
my
schema
in
graph.
Ql
speak
using
their
data
types.
I
won't
go
through
all
of
that
detail,
but
when
I
do
that,
I
can
then
start
to
add
the
actions
and
in
graph
QL.
A
That
means
that
you
actually
have
to
implement
the
resolver.
So
I
start
with
basically
a
scaffolded
list
of
all
of
those
resolvers
and
I
start
to
say
you
can
do
this.
You
can
do
that
and
it's
all
still
attached
to
the
schema,
but
you
had
to
kind
of
put
it
together
by
hand.
It's
not
bad.
It's
actually
much
better
than
we
used
to
do,
but
I
think
we
can
even
do
better
than
this.
Now
we
can
talk
about
is
graph
QL
different
than
rest
or
not.
I
won't
have
a
lot
of
time
to
say
here.
A
What
I
would
encourage.
You
is
look
at
all
of
this
understand
how
it
all
relates
to
each
other
then
make
the
choices
that
you
actually
need,
and
what
I'm
gonna
try
to
do
is
show
you
how
it
all
relates
to
each
other.
So
let's
go
back.
Oh
and
one
other
thing
you
get
out
of
graph
QL
like
you
do
with
the
others,
is
once
you've
actually
captured
it
in
a
specification
effectively.
Then
you
can
generate
the
tooling
out
of
it
right.
A
Then
you
can
actually
create
queries
and
browse
the
results
and
explore
the
the
API
that
you've
generated
through
graph
QL
again
once
you've
crossed
that
threshold.
This
is
really
really
compelling
and
it's
still
attached
up
to
our
schemas
and
it's
still
attached
up
to
the
domain
model
very
explicitly,
but
you
had
to
kind
of
wire
together
the
actual
API
side
by
hand.
A
So,
if
we
do
that,
here
is
another
expression
of
our
data
types,
exactly
the
same
schema
that
you
saw
before
this
one
is
with
Ravel
data
types
just
makes
it
a
little
bit
easier
to
actually
read
what
it
is
that
we've
done
and
we're
gonna
start
to
capture
those
patterns.
Those
repeatable
patterns
that
we
want
to
do
inside
of
a
reusable
library.
So
here
you
see,
for
example,
the
general
behavior
of
any
collection.
Any
collection
I
should
be
able
to
retrieve
it.
A
I
should
be
able
to
create
a
new
thing
in
that
I've
captured
all
of
the
HTTP
nests
inside
of
these
reusable
patterns.
So
when
I'm,
creating
new
API
is
I,
don't
have
to
relearn
HTTP
and
maybe
make
some
mistakes,
but
I
can
actually
get
consistent.
Api
is
flowing
out
of
it,
and
so
with
that,
my
API
specification
looks
like
this
much
simpler
than
it
was
before
much
more
obvious.
A
What
it
is
that
I'm
doing
I've
got
shopping
carts
that
are
a
collection
and
here's
their
schema,
whether
you're
reading
them
or
writing
them,
and
then
here's
a
particular
item
in
a
shopping,
cart
and
here's
its
schema
and
so
on
and
so
forth.
So,
in
the
end,
I've
got
a
simpler
and
more
concise
description
of
what
my
API
is
and
I.
Take
that
and
again
I've
got
to
generate
UI
is
out
of
this
thing.
I
can
generate
my
open
API
scheme.
A
Out
of
this
thing,
all
the
other
tools
that
I
saw
before
are
still
available
to
me
in
a
more
concise
way.
To
actually
do
that
modeling.
So
a
lot
of
people
will
go
and
do
that,
can
we
do
better?
Well,
yes,
the
more
opinionated
we
become,
the
more
prescriptive
would
become
the
more
constrained
we
become,
the
more
straightforward
we
can
actually
attach
to
that
simple
model
that
we
had
at
the
beginning
and
rest
seems
to
be
the
best
fit
for
that.
A
It's
not
as
I
will
argue
it's
not
that
you're
going
to
do
rest
and
you
can't
do
everything
else.
You
can
actually
do
a
lot
of
things
on
top
of
rest,
but
if
you
attach
that
restful
domain
model
directly
to
your
that
restful
api
model
directly
to
your
domain
model,
you
will
get
a
cleaner,
more
utilitarian
api.
Let's
see
what
that
looks
like.
A
So,
let's
go
back
here
to
my
schema
and
I'm
going
to
remove
the
relationships
for
a
moment
because,
with
rest,
the
most
important
thing
to
do
is
to
establish
what
are
the
resources
in
your
API
right,
and
you
do
that
here
at
the
at
the
data
model
level,
so
I'm
going
to
take
a
few
of
them
and
those
are
the
resources
that
actually
want
to
expose
in
my
API
right
I'm,
not
writing
any
kind
of
code.
I'm
literally
just
saying
these
resources
have
URLs
attached
to
them.
That's
the
first
element
once
I.
A
Do
that
all
these
other
things
get
folded
into
those
resources
right,
just
like
we
saw
before
so
they're.
Still
there
they're
just
not
directly
exposed
they're
encapsulated
inside
of
these
resources
inside
of
their
properties,
and
once
I've
done
that,
then
I
need
to
move
them
around
a
little
bit.
So
I'm
doing
this
to
show
you
that
I'm
not
losing
anything.
A
It's
like
one
of
those
card
shufflers,
it's
all
still
there
I'm
just
moving
it
to
a
different
place
where
it's
a
little
bit
more
convenient,
because
what
I
need
to
do
is
I
need
to
add
a
couple
more
things
to
this
model,
which
is
collections
of
things
so
anytime,
I
have
individual
things.
I
always
will
need
collection,
so
I'm
going
to
add
those
guys.
A
So
there's
the
shopping,
carts
collection
and
there's
the
checkouts
collection
right
to
just
aggregate
lists
of
these
things,
and
that's
actually
all
I
will
need
with
respect
to
resources,
because
at
this
point,
I
can
simply
apply
rest
to
this
I
simply
say:
there's
a
uniform
interface
that
you
always
do
exactly
the
same
thing.
Every
time
you
have
a
collection,
you're,
always
going
to
be
getting
it
or
creating
something
new
inside
of
it.
Every
time
I
have
an
item
inside
of
a
collection
I'm
always
going
to
be
doing
exactly
these
kinds
of
operations.
A
These
operations
have
a
meaning
inside
of
rest.
I
can
just
tag
them
with
which
meanings
to
actually
want
to
expose.
In
my
API,
it's
it's
no
harder
than
this,
and
what's
even
more
interesting,
is
the
actual
transitions
between
them.
So
now
these
aren't
entity
relationships
one-to-many.
This
is
the
way
you
move
from
one
thing
to
another,
so
your
business
process
is
actually
encoded
in
here.
A
If
I
want
to
check
out
from
a
shopping
cart,
this
tells
me
declaratively
that
I
need
to
post
to
a
checkouts
collection
and
create
a
new
check
out
that
thing
when
you
say
check
out
and
you're
sitting
there
and
you're
verifying
your
orders.
Okay,
that's
encoded
right
here,
I,
don't
have
to
write.
Anything
else.
Rest
just
gives
me
this
out
of
the
box.
A
That's
really
really
compelling
so
I've
now
achieved
a
domain
model
and
the
data
model
and
a
very
direct
attachment
of
the
API
is
to
my
data
model
and
before
you
say
yeah,
this
is
another
one
of
the
ten
year
philosophy.
Talks
about
rest
I
want
to
show
you.
This
is
actually
real
right
and
it's
very
straightforward
to
actually
do
take
that
same
model
that
we
had
before
and
simply
add
annotations
very
set
of
prescriptive
annotations
that
you
stuck
inside
of
some
libraries
so
that
everybody
else
can
say
yeah.
A
This
is
what
I
meant
by
rest
and
you
attach
them
so,
for
example,
in
here,
I
simply
annotated,
I
told
the
system
that
this
thing
is,
in
fact
a
resource
of
type
checkout,
and
that
this
thing
in
terms
of
general
resource
type,
is
a
member
of
a
collection
right.
So
now
there's
no
argument
about
this.
You
don't
have
to
read
some
documentation.
Any
API
client
can
discover
that
this
thing
is
a
resource
and
can
knows
what
to
do
with
this
kind
of
thing.
A
So,
for
example,
it
knows
that
these
operations,
the
read
in
the
update,
correspond
to
get
input.
Otherwise,
somebody
would
have
had
to
write
that
and
make
sure
did
they
use,
put
or
patch
sure
what
did
they
actually
do?
It's
actually
encoded
right
here
in
the
metadata.
It's
completely
declarative.
Similarly,
with
all
of
the
hideous
all
of
the
transitions
between
things
are
actually
declared
for
you
inside
of
this,
so
rest
is
just
a
pattern
on
top
of
our
existing
API
specifications
and
it
can
all
be
made
real
okay,
so
we
think
we're
done
with
api's.
A
Of
course,
this
conference
tells
you
we
are
not
done
with
API,
there's
a
bunch
more
stuff
to
do,
because
everything
that
we've
done
so
far
is
sitting
on
top
of
HTTP
with
request
response.
But
that's
not
all
there
is
out
there.
So
systems
can
talk
to
each
other,
a
synchronously
through
notifications,
for
example,
right.
We
all
get
that
on
our
iPhones
and
we
know
that
IOT
out
there
feeding
tremendous
amounts
of
little
bits
of
events,
they're,
not
waiting
for
you
to
respond
they're,
just
feeding
it
in
right
temperature
temperature
temperature.
A
So
we
know
that
at
least
these
things
are
important,
but
in
fact,
in
any
company-
and
in
fact,
and
anything
that
you
do
there
are
tasks
I
need
to
produce.
Pdfs
I
need
to
generate
something.
All
of
these
kind
of
offline
tests
are
important
and,
in
general,
the
way
companies
work
and
increasingly
the
way
that
we
work
is
through
workflows,
and
these
tend
to
be
asynchronous.
Something
happens
that
triggers
something
else
to
happen
that
triggers
something
else
to
happen.
A
That's
that's
built
into
automation,
yet
we
haven't
captured
any
of
that
stuff
so
far,
and
if
you're
in
the
world
of
micro
services
and
you're
thinking
you
know
this
is
all
this
is
all
a
really
cool
new
way
to
do
things
and
you're
talking
about
event
sourcing.
Well,
that's
nothing,
but
a
bunch
of
events
that
one
of
your
micro
services
generates
that
another
one
consumes
and
it
generates
its
events
and
so
on.
So
this
pattern
has
got
to
somehow
make
it
into
our
world
of
api's.
Let's
look
at
that.
A
So
what
is
the
general
architecture
here?
These
various
applications
are
publishing
events
and
subscribing
events,
usually
there's
some
broker
in
the
middle
right
and
before
you,
you
think
this
is
just
enterprise.
Messaging
Kafka
is
certainly
a
very
good
example
of
this.
So
there's
something
in
the
middle
that
takes
the
events
and
then
publishes
them
pushes
them
to
the
subscribers,
such
that
the
publishers
and
subscribers
don't
have
to
be
there
at
literally
the
same
time
and
there's
different
semantics.
A
I
won't
get
into
that,
but
somewhere
there's
an
API
in
here,
because
these
are
applications
interacting
with
each
other
they're,
not
interacting
through
request
response,
but
they
are
interacting
with
each
other.
You
can
make
this
application
do
something
by
publishing
events
to
it,
so
there
is
an
API
somewhere
and
we
should
capture.
The
question
is:
where
is
that
API?
It's
kind
of
a
Where's
Waldo
kind
of
thing,
so
here
it's
very
clear
where
the
API
is.
It
sits
right
on
top
of
the
application
that
actually
answers
their
requests,
but
where's
the
API
here.
A
This
is
actually
a
contract
between
publishers
and
subscribers.
So
there
is
really
a
contract.
It's
kind
of
this
distributed
contract
right
now.
It's
implicit
and
my
urging
and
I
think
where
we're
going
as
an
industry
is
to
make
that
explicit
as
an
invented
API
as
a
contract
between
publishing
subscribers
that
has
all
the
benefits
of
an
API
spec
that
we
attribute
to
request
response
kind
of
interactions
so
easier
way
to
envision.
That
is
when
you
have
only
one
publisher,
which
is
the
case
much
of
the
time
not
always
in
that
world.
A
You
can
just
move
that
up
underneath
here
and
now
you
can
say
hey.
This
is
an
API,
that's
exposed
by
the
publisher
of
the
events,
it
kind
of
controls
the
shape
of
these
events.
That's
why
it's
good
to
associate
it
with
that.
So
if
that's
the
event
at
API
where's
the
event
at
API,
spec,
well,
we'll
get
there
in
a
moment.
Remember
we're
not
going
to
start
from
that.
We're
gonna
model
it
inside
of
our
domain.
So
now
we're
adding
something
new
in
our
domain
purchased
completed.
That's
a
business
event!
A
Business
people
know
what
to
do
with
that.
Everybody
can
agree
that
that's
what
it
means,
no
matter
what
the
data
is
and
at
the
data
level
we
can
add
payment
created
and
what's
interesting
about
capturing
that
data.
So
far,
this
has
just
been
about
static
data,
but
now,
with
events,
we
start
to
see
the
temporal
aspect.
We
start
to
see
the
business
flows
in
the
data
level.
That's
really
interesting!
How
about
at
the
API
level?
Well,
we
can
add
right
in
here
at
our
declarative,
API
level
and
you
think,
a
publish
and
a
subscribe.
A
That's
actually
really
the
way
the
world
works.
When
you
go
to
pay
for
something
you
go
to
the
credit
card
and
you
kind
of
given
your
information
and
then
at
some
point
they
give
you
back
a
token
and
you
go
and
publish
this
to
some
listener.
That
goes
and
verifies
that
the
payment
is
there
and
then
you
subscribe
to
hey.
Did
the
order
go
through
and
then
you
find
out?
So
that's
the
way
to
reconcile
all
of
these
different
capabilities.
A
Now
we
need
a
spec
and
for
that
spec
I
want
to
invite
on
stage
Fran
Mendez
a
creator
of
async
API,
which
is
an
emerging
spec
that
it's
it's
worth,
you're
paying
attention
to
just
like
Ramo.
Just
like
open
api
async
api
tries
to
capture
all
of
those
interactions
right
here.
All
right,
Fran
come
on
up
you're.
B
Thanks
for
the
invitation
sure
so
how
many
of
you
are
familiar
here
with
the
open,
API
or
rommel,
let
me
see
you
okay,
so
fair
enough
cool.
So,
as
I
was
saying,
there
was
a
missing
part
here,
we
were
used
to
define,
request
response
interactions,
but
not
even
driven
interactions
right
so
created
the
async
API
specification,
which
is
pretty
much
like
an
open
API
and,
as
you
can
see,
on
the
arrows
on
top,
you
get
channels
channels.
B
Are
this
information
like
these
events,
like
payment
created
right
things
like
that,
and
you
can
define
their
interactions
like,
for
instance,
it
says
channels,
checkouts,
checkout,
ID,
payments,
pavley's
message,
and
it
means
that
this
application
is
going
to
publish
a
message
into
the
check
out,
check
out
the
payments
Channel
and
you
can
find
there.
The
payload
is
a
trammel.
B
So
you
can
declare
there
that
please
use
these
headers
and
you
don't
repeat
yourself
all
the
time
right
so
just
to
make
the
connection
here
all
this
information
that
is
referenced
there,
payment
right
and
order
it's
coming
from,
in
this
case
a
trammel
library.
So
you
have
all
the
data
defined
on
a
rumble
file,
and
that
leads
me
to
the
other
cool
feature
that
we're
launching
soon
is
support
for
any
schema
format.
Any
ml
or
JSON
schema
format
like
Rommel,
like
JSON,
schema,
of
course,
like
Avro,
for
instance,
with
Kafka.
B
This
is
a
I
think
it's
a
good
example,
because
many
people
in
even
driven
world
is
using
avril
and,
as
you
were
saying
before,
out
of
the
left
side,
you
get
the
right
side
right
generator,
so
you
get
human
readable
documentation
just
for
free.
Really
it
really
quick
and
without
you
having
to
worry
about
that
deal,
there's
all
the
details
of
things
right.
So,
if
I'm
not
mistaken,
this
is.
C
A
It's
great
to
have
the
world
of
events
come
into
the
world
of
api's,
so
I
wanted
to
leave
you
with
a
couple
of
takeaways
right.
I've
talked
through
a
lot
of
things
right,
there's
some
ways
to
mark
to
follow
through
this,
so
one
is
if
you're,
actually
looking
for
the
content.
That
was
all
there.
You
can
go
on
our
github
and
just
look
at
the
models
and
we'll
be
evolving
that
over
time,
there's
nothing
official
about
this.
It's
very
very
scrappy.
A
There
is
actually
a
mechanism
to
pull
all
of
this
stuff
together,
created
something
called
a
anything
modeling
language
right,
which
is
way
really
to
model
any
kind
of
domain.
You
can
find
it
out
there
in
a
dot
ml.
It's
all
open
source.
Please
come
in
to
contribute.
If
you
want
to
contribute
this
level,
it's
relatively
deep.
It
uses
all
these
w3c
technologies,
if
not
just
wait
for
the
outputs
of
all
the
lists
to
come
out,
and
it
will
allow
you
to
model
all
of
these
domains
and
then
some
you
can
model
kubernetes
in
this.
A
You
can
model
a
lot
of
things,
so
hopefully
the
slides
will
be
distributed
later.
So
I
want
to
leave
you
with
one
last
thought,
and
that
is
what
I'm
trying
to
do
is
I'm
trying
to
keep
things
as
simple
as
possible
and
as
you
go
through
the
following
days
and
you
you
listen
to
all
of
these
amazing
technologies
and
you
get
deep
down
into
the
implementations
and
so
on.
A
Try
to
strive
for
that
simplicity,
whether
it's
at
the
domain
model
or
at
the
API
model
or
at
the
patterns
model,
and
if
we
don't
get
that
simplicity
right,
we're
gonna
be
drowning.
The
way
the
last
wave
of
API
is
known
as
soap
drowned.
So
that's
what
we
want
to
avoid.
We
want
to
actually
keep
leaning
into
this
thing
and,
as
we
actually
find
that
simplicity,
we're
going
to
be
able
to
get
everyone
aligned
around
this
and
get
all
the
leverage
out
of
the
api's.
So
with
that
I
want
to
say
thanks.
D
A
A
So
all
these
things
are
really
very
interrupt
right
now
and
if
you
ping
me
later,
I
guess
my
slide
is
off.
But
if
you,
if
you
contact
me,
I'm,
happy
to
connect
you
or
just
go
to
a
dot
ml
and
you
will
actually
find
links
from
there
and
that's
a
really
critical
point
like
we're,
not
in
the
business
of
replacing
everything,
we're
in
the
business
of
making
everything
interoperable
and
making
sure
that
new
things
are
even
more
consistent
than
we
were
than
they
were
before
any
other
questions.
D
A
Since
I
have
many
layers,
there's
different
kinds
of
things
so
in
the
schema
I
think
it's
it's
exactly
how
you
would
have
thought
before
you
literally
there's
a
way
to
encode
them
inside
the
files
it's
not
different
than,
for
example,
the
way
you
would
have
done
it
in
ER
diagrams.
That
notion
for
the
data
perspective
is
completely
typical
in
the
rest
world.
There
you're
talking
much
more
about
transitions
right,
so
it's
modeled
through
collections
when
you
have
a
collection
of
something.
A
E
So
so
the
whole
purpose
of
this
is
to
automatically
generate
the
rest
code
from
the
data
models
right,
so
I
didn't
quite
follow
when
you
show
the
you
know
the
schematic,
how
that
would
work
right
if
I
have
two
entities
with
a
many-to-many
relationship,
does
it
automatically
create
an
intermediate
mapping
entity
or
how
does
that
work?
Yeah.
A
So
they
for
the
for
the
server
side
of
that
right
when
you're
actually
generating
the
api's
there's
nothing
fundamentally
different.
At
the
API
level,
the
API
level
is
still
a
contract
at
the
HTTP
level,
but
it's
now
got
extra
information
that
can
be
used
either
by
the
implementation
underneath
or
by
the
clients
right.
So
the
clients
have
a
very
declarative
way
of
navigating
through
this
and
understanding
what
it
is
that
they're
actually
encountering
at
that
moment
from
the
server
implementation.
You
can
use
that
and
I.
Don't
think,
there's
that
many
tools
today.
A
So
this
is
a
call
for
the
community
to
go
and
take
that
metadata,
underneath
that
and
actually
generate
scaffolded
implementations
based
upon
the
relationships
that
you've
established.
There
are
tools
already
for
scaffolding
out
pretty
well
at
the
data
model
level,
and
the
data
model
part
is
no
different
again
than
it
was
before,
but
as
far
as
the
API
model
goes,
when
you're
doing
those
transversals
I,
don't
think
there
are
that
many
tools
out
there
that
are
well
developed.
F
Yes,
I
think
we
have
covered
the
data,
definitions
and
models,
but
there
are
also
business
rules
governing
how
the
data
gets
in
and
gets
out
is
the
metadata
definition
which
was
used
in
rimmel
capable
of
delivering
those
business
rules
out
to
the
client.
So
they
can
expect
what
to
how
the
APS
would
behave.
A
Some
of
the
business
rules-
yes
and
some
of
the
business
rules
no
and
I
think
the
the
really
interesting
thing
is
about
business
rules.
Is
you
don't
actually
want
to
expose
all
of
them
on
the
front
side
of
the
API?
There
are
many
things
that
you
want
to
abstract
out
for
two
reasons:
one
is
it's
kind
of
none
of
the
clients
business
and
how
you
actually
do
that.
A
So,
for
example,
when
I
create
the
the
when
I
create
a
payment,
what
are
the
business
rules
about
verifying
and
so
on
obviously
should
not
be
in
there,
but
the
other
reason
is
because
if
you
do
expose
all
of
the
business
rules
behind
the
scenes,
you
will
end
up
coupling
the
client
to
them
and
that's
actually
pretty
hard.
Having
said
that,
there
are
business
rules
that
you
actually
want
to
explain.
One
of
the
business
rules
is
obviously
what
are
the
business
flows,
so
what
happens
from
here
to
here
and
so
on?
A
You
do
actually
end
up
reflecting
that
in
that
restful
model
and
as
much
as
possible,
those
should
be
conventional
right.
So
there's
no
there's
no
big
surprises
in
there.
For
the
parts
of
business
rules
that
have
to
do,
for
example,
with
validation
right,
so
the
amount
of
this
order
must
be
above
this
and
so
on.
You
can
actually
capture
those
in
in
your
schema
rules
and
and
put
constraints
on
them
such
that
those
parts
of
the
business
rules
are
actually
at
the
data
model,
and
then
there
are
other
business
rules
that
have
to
do
with.
A
When
you
do
this,
this
happens
and
when
you
do
that
that
happens,
kind
of
a
workflow
set
of
business
rules.
You
often
see
those
inside
of
companies.
Those
are
particularly
interested
because
so
many
of
those
are
actually
event
based
and
when
you
have
the
async
API
specs
across
lots
of
events,
you
can
bring
them
back,
recreate
the
choreography.
That's
actually
happening
there
and
effectively
in
that
way
announce
what
the
business
rule
actually
is.
So
there's
lots
of
levels
of
that.
Thank.