►
From YouTube: Thinking Out Loud #16 — with Jeremy Whitlock
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello
folks
welcome
once
again
to
thinking
out
loud.
My
name
is
fran
mendes
and,
and
today
we're
gonna
have
a
nice
guest
for
you
who
have
been
in
the
in
the
api
space
for
a
while,
specifically
in
the
api
specification
space
and
I'll,
tell
you
more
about
him
in
a
while.
So
before
we
get
started,
let
me
go
through
the
usual
messages.
A
A
A
So
that
means
that
you
can
join
and
please
do
it.
We
we
like
to
to
welcome
people
and
to
and
yeah
and
to
read
the
questions
or
the
comments
that
you
might
have
right
so
feel
free
to
join
the
the
conversation
and
yeah.
Don't
be
shy,
ask
anything
you
want,
and
last
but
not
least,
full
lacing
kpi.
Of
course
right.
We
do
not
just
thinking
out
loud,
but
we
do
a
bunch
of
other
stuff
and-
and
I
think
it
will
be
really
good
for
you.
A
If
you
follow
us
and
and
if
not
you
can
always
unfollow
it.
So
that's
that's.
That's
also
cool
the
topic
for
today
is
that
we're
gonna,
as
some
of
you
may
know,
we're
working
on
a
next
version
for
the
parser
right
and
and
that
parser
is
like
kinda
decoupling
from
the
specification
structure
right.
So
that
means
that
it
will
become
kinda
like
an
sdk,
maybe
not
just
a
parser.
A
It
is
more
thinking
about
the
user
perspective,
what
the
user
needs
and
less
about
what's
the
structure
of
the
document
itself,
so
that
is
done
in
case.
We
release
a
breaking
change
on
the
spec,
then
the
parser
doesn't
necessarily
have
to
have
a
breaking
change,
because
it's
obstructed
away
from
the
structure
of
the
spec.
A
So
our
guest
today
he
had
some
experience
like
I
said
in
in
api
specifications,
but
I'm
not
going
to
wait
longer,
I'm
going
to
introduce
jeremy,
so
jeremy
jeremy.
With
luck
welcome,
you
might
want
to
introduce
yourself
a
little
bit
cool.
B
B
I
started
out
using
open
api
back
when
it
was
called
swagger
back
in
2011
at
a
startup
and
whenever
I
joined
apogee
we
very
quickly
started
building
tooling
around
open
api
and
integrating
with
open
api,
and
so
we
started
you
know
contributing
back
to
the
community
and
we're
heavily
involved
for
a
number
of
years
and
yeah
I
mean
that's.
That's
that's
me
as
it
pertains
to
this
podcast.
A
Nice,
that's
really
cool
to
hear.
Actually,
I
was
saying
that
jeremy
has
a
lot
of
experience
in
api
specifications.
He's
been
there
for
a
while,
like,
as
he
said,
he's
joined
the
tse
since
the
very
beginning.
Was
it
I
think
when
it
was
donated
to
a
linux
foundation
right.
B
A
B
Yeah
yeah
at
the
time,
so
apogee
was
working
with
reverb,
which
were
the
people
that
started
and
owned,
swagger
the
trademark,
the
product
or
the
tooling
and
so
on,
and
you
know
contributing
it
to
the
the
linux
foundation
just
made
a
ton
of
sense.
You
know
not
having
some
corporate
entity
owned,
the
spec
was
a
huge
win
for
the
community.
In
my
opinion,
and
you
know
that's.
I
think
that
I
mean
that
was
a
huge
turning
point
for
I
think
for
open
api.
So
yeah.
A
A
Okay,
okay,
okay,
perfect!
So
I
was
I
was
trying.
I
was
thinking
on
something
and
then
I
completely
forgot
it
yeah.
So
many
many!
No!
No!
No!
No!
No!
No!
No!
No!
No!
No!
No!
No!
No!
No,
no
worries!
So
many
people
are
asking
me
in
in
in
private,
sometimes
like
hey.
A
How
do
I
join
the
async
api
tsc
right
and
for
us
it's
clear
like
we
made
it
public
how
and
we
even
make
it
like
we
do
how
to
contribute
live
streams
with
lucas,
where
he
explains
like
how
to
contribute
to
the
spec
or
to
the
tools
and
how
to
contribute,
as
in
kpi
in
general,
and
also
he
even
made
a
a
talk
about
how
to
join
the
tse
right.
A
The
different
paths
to
end
up
joining
the
tse,
but
I'm
curious,
I
more
or
less
know
myself
how
it
works.
But
what's
the
path
to
to
join
the
open
api,
tsc.
B
B
You
know
so
you're
looking
at
the
github
issue,
tracker
or
writing
documentation,
building
some
value-add
tooling
things
like
that,
and
then
at
some
point
you
know
you
start
joining
the
tsc
meetings
and
I
mean
I,
the
tsc
has
a
you
know
an
on-boarding
process
as
well,
but
for
the
most
part
I
mean,
I
think
you
know
it's,
it's
really
just
about
being
involved.
You
know
any
capacity
and
then
getting
to
the
point
where
you
provide
enough
value
to
where
you
get
dominated.
B
You
know,
then
we
vote
and
we
go
about
our
business.
But
I
think
it's
a
you
know
it's
a
very
traditional
open
source
model.
You
know
meritocracy,
kind
of
thing
and
there's
nothing
stopping
you.
I
mean
that's
one
of
the
best
things
about
you
know:
async,
api
and
open
api.
Being
you
know,
community,
you
know
projects
is
that
everything
that
is
done
to
you
know
manage
and
run.
The
community
is
done
in
the
open,
so
I
mean,
if
you
have
an
interest,
I
mean
there's
nothing,
stopping
you
from
getting
involved.
B
A
Yeah,
of
course,
so
so
folks,
who
are
watching,
if
you
have
any
questions
about
you
know
like
like
open
api
tse
or
whatever
they're
doing
feel
free
to
to
shoot
them
on
the
on
the
chat,
and
I'm
I'm
sure
that
jeremy
will
be
happy
to
reply
to
the
best
that
he
can.
Of
course,
don't
be
bad,
don't
be
bad
with
him.
It's
his
first
time
around.
The
podcast
treat
him
well
so
jump
into
a
different
topic.
So
this
whole
thing
like
started.
A
This
live
stream
started
because
so
I
I
offered
to
to
I
offered
you
to
join
me
on
thinking
out
loud
because
we
were
speaking
about.
I
was
publishing
something
on
twitter
about
the
parser.
The
current
parser
work
that
we're
doing
for
the
next
version,
next
major
version
of
the
parser,
and
also
for
the
next
major
version
of
the
spec,
it's
kinda
related
so
and
you
and
you
jumped
into
the
conversation
like
like
hey,
it's
a
yeah.
I've
been
through
the
same
through
the
same
process.
A
B
Oh
for
sure
I
could
talk
about
this
for
a
while.
So
when
apogee
first
started
getting
involved
in
open
api,
I
mean
you
know
we
were
helping.
We
were
helping
reverb,
you
know
really
design
and
push
out
the
2.0
release
of
swagger
at
the
time
and
one
of
the
things
that
we
realized
was
that
you
know
there
was
no,
you
know
community-led
parser
or
validator.
I
mean
there
was
a
parser,
but
you
know
the
whole
idea
behind.
B
B
You
know
bad
open
api
documents
and
so
one
of
the
first
actually,
the
first
project
that
that
you
know
apogee
was
working
on.
Was
this
project
called
swagger
tools
and
to
this
day
it's
probably
one
of
the
more
popular
projects
we
worked
on,
but
it
was
heavily
flawed
in
that
we
started
this
project
as
nothing
more
than
a
command
line,
interface
for
validating
swagger
documents,
so
swagger,
1.2
and
2.0,
and
so
that
was
the
whole
idea.
You
know
provide
a
command
line.
B
Interface
that
could
validate
your
swagger
documents
and
validating
was
something
that
there
was
no
spec
on.
You
know,
thankfully,
with
the
open
api
doc
being
structured.
The
way
it
was,
you
had
a
json
schema
that
could
help
you
structurally
validate
an
open
api
document,
but
there's
actually
a
lot
of
semantic
validation.
That
needs
to
happen
for
your
open
api
document
to
be
completely
valid,
and
you
cannot
do
that
with
json
schema,
and
so
when
we
started
working
on
swagger
tools,
it
started
off
with
all
right
version.
One.
Let's
take
the
open
api.
B
Json
schema
validate
the
document
based
on
that
and
then
beyond
that
we're
going
to
read
through
the
spec
with
you
know:
fine
toothed,
home
and
figure
out
all
the
places
where
it
says
you
know
it
creates
these
rules
that
aren't
validated
through
open
api
or
through
the
json
schema.
So,
for
example,
a
really
good
example
of
this
is
you
can
have
two.
You
know
swagger
pads
or
open
api
pads
that
are
unique
and
that
the
text
is
not
the
same,
but
they
are
functionally
the
same.
B
So
you
could
have
forward
slash
paths
or
pets
and
then
have
a
path
parameter
named
pet
id.
But
then
you
could
also
have
in
another
place
forward,
slash
pets
and
instead
of
pet
id
you'd
have
pet
name
so
functionally
they
are
identical,
http
pads
and
you
cannot
catch
that
with
with
you
know,
json
schema.
So
you
know
the
next
iteration
of
swagger
tools,
the
cli
was
to
start
doing
semantic
validation
and
then
once
we
did
that
you
know
we
started
building
products
around
it.
Well,
swagger
tools
was
built
as
a
command
line
interface.
B
It
wasn't
an
api,
it
wasn't
connect
middleware,
but
what
we
did
was
we.
Basically,
you
know
bastardized
swag,
swagger
tools,
the
cli
for
lack
of
a
better
phrase,
and
you
know
exposed
like
a
crafty
api
on
top
of
it
and
based
on
that
api,
we
built
some
connect,
middleware,
which
is
really
really
cool,
and
then
that's
where
we're
like,
hey.
You
know
we're
kind
of
in
a
bad
spot.
B
We
we
had
this
really
cool
cli
that
exposed
a
really
crappy
api
and
we've
got
these
really
cool
tools
built
on
top
of
it,
and
now
we
need
to
rebuild
it
and
that's
where
a
project
I
created
called
sway,
which
really
focused
purely
on
creating
you
know
it
an
api
or
an
abstraction
on
top
of
the
spec,
where
we
still
would
do
the
same
kinds
of
things,
but
you
would
have
a
programming
programmatic
interface
for
parsing
documents.
Getting
errors
you
know
doing
you
know
having.
B
You
know,
custom
validation
that
way
that
eventually,
you
could
do
eslint
style
linting
of
your
apis,
and
it
was
such
a
cool
idea.
If
we
would
have
started
there,
it
would
have
been
great,
but
you
know
when
we
were
in
the
process
of
updating
sway
for
open
api
three.
You
know
we
got
acquired
by
google
and
you
know
there
was
just
a
lot,
a
lot
of
lost
momentum.
It
also
didn't
help
that
there
wasn't
a
lot
of
community
involvement.
B
You
know
so
you've
got
other
companies
that
are,
you
know,
basically
building
their
own
parser
building
their
own
libraries,
and
so
me
doing
this
on
my
own
time.
I
can't
compete
with
people.
You
know
that
that
their
day
job
and
their
team
of
people
are
working
on
it
to
do
the
same
thing,
so
that's
kind
of
the
that's
my
that's
been.
B
My
experience
was
that
we
got
into
it
kind
of
the
wrong
way
and
I
think
that
what
you're
doing
makes
a
ton
of
sense,
because
if
we
would
have
done
it
the
right
way,
I
think
that's
what
we
would
have
ended
up
with.
B
We
would
have
ended
up
with
an
api
for
looking
at
an
open
api
document
programmatically
and
then
having
the
cool
little
connection,
points
to
create
custom
validations,
and
you
know
lint
style
tooling,
I
mean
sway-
was
really
built
to
be
a
library
for
open
api,
tooling
developers,
whereas
swagger
tools
really
started
out
with
a
finite
set
of
features
and
was
kind
of
mangled
to
support
other
things.
So
that's
kind
of
where
we,
you
know,
wear
swagger
tools
and
sway.
A
So
you
actually
mentioned
one
word
intent
right,
so
that
sorry
I
was.
I
was
also
writing
on
the
chat
because
I
was
it
was
getting
frozen
for
me,
but
I
think
it's
my
connection
so
yeah
it
will
be
fine
for
the
rest
of
the
audience.
I
was
losing
you
from
time
to
time,
so
you
said
intent
and,
and
that
to
me
it's
a
it's
a
clear.
A
A
Yeah
you're
right,
I
still
don't
apologize
yeah,
so
so
actually
intent.
What's
the
intent
of
the
user
right,
like
is
the
user
like
a
final
user
or
is
the
user
a
tooling
vendor
right?
So
if
you're
a
final
open,
api
user
or
async
api
user,
you
might
want
to
do
certain
things
with
the
document
and
but
if
you
are
a
tooling
vendor,
you
might
want
to
do
a
different
set
of
things
right,
like
they're
sure
that
the
the
end
user,
that
don't
care
about
example,
is
like
I
want
to.
A
I
don't
know,
query
all
the
messages
here
and
then
in
the
document
or
query
in
the
case
of
opening.
I
query
all
the
paths
or
you
know,
get
a
list
of
paths
or
or
get
a
lift,
get
a
list
of
all
the
post,
a
get
a
list
of
all
the
post
operations
on
each
path
right,
like
yeah
as
a
user.
You
might
want
to
do
that,
but
that's
not
usually
the
case
right.
You
might
that's
usually
like
what
a
tooling
vendor
wants
to
do
because
they
might
want
to
list
in
their
tools.
A
They
want
to
list
all
the
past
calls
or
the
get
calls
or
the
you
know
so
so
yeah
so.
B
I
think
that
that's
a
lot
more
important
than
we
realize,
though,
because
you
know,
of
course,
tooling
vendors.
You
know
they
want
to
build
some
tool,
maybe
make
some
money
or
you
know,
provide
some
services
around
it
and
so
on.
But
you
know
if
you
look
at
async
api
and
open
api
as
your
contract,
it's
not
only
the
contract
you
have
to
or
that
your
users
and
your
clients
have
to
uphold
it's
the
client
that
you
have
to
uphold
so
a
lot
of
times.
B
What
we
were
realizing
was
that
you
know
having
a
parser
and
validator
was
great
for
the
document
itself,
but
we
really
wanted
to
be
able
to
use
parts
of
that
document
for
code
generation,
documentation
generation.
Those
are
the
two
use
cases
we
all
know
of,
but
we
also
wanted
to
put
them
into
our
server
frameworks.
B
B
That's
kind
of
how
swagger
tools
you
know
ended
up
becoming
with
swagger
tools
like
I
say
it
started
out
as
a
cli,
because
the
need
was
that
you
know
we
wanted
to
solve
the
garbage
in
garbage
out
problem
where,
if
you've
got
a
bad
spec,
we
want,
we
don't
want
to
do.
You
know,
requests
and
response
validation
if
you
don't
have
a
good
res
request
or
response
body
or
whatnot,
and
you
know
with
it
being
easy
to
alter
bad
documents.
B
You
know
myself
and
a
guy
by
the
name
of
scott
gagno
who
worked
with
we
both
worked
together
on
the
apogee
tooling,
for
open
api.
We
were
speaking
at
conferences
quite
often
about
what
we
what
we
called.
I
don't
know
if
we
coined
the
phrase,
but
it
was
called
design
driven
apis
and
the
idea
was
that
with
the
right
tooling,
you
could
basically
create
an
api
specification
and
then
drive
that
tooling
purely
from
the
spec.
B
To
do
you
know,
routing
request,
response,
validation,
all
mock
responses
like
generate
mock
servers,
and
that
was
where
a
lot
of
the
apogee
clients
at
the
time
were
really
benefiting
from
some
of
these
features,
and
like
I
say
we
just,
we
happened
to
have
started
in
a
way
that
that
made
that
a
lot
harder
than
it
should
have
been
and
sway
was,
was
the
the
library
that
I
created
on
my
own
time,
because
we
had
decided
that
we
didn't
want
to
go
that
route.
But
I
was
like
man.
B
This
is
really
important,
let's
create
a
library,
for
you
know,
people
to
integrate
with
and
build
around
open
api,
and-
and,
like
I
say,
that's
that's
where
I
feel
like
there
was
a
lost
opportunity,
because
we
never,
you
know,
brought
that
completely
to
fruition.
We
we
did
for
2.0,
and
we
were
in
the
process
of
rewriting
all
of
the
swagger
tools.
Middle
connect
middleware
to
work
with
sway,
but
we
just
we
lost
momentum
and
time.
B
That's
just
what
happened,
but
I
actually
think
that
that's
I
mean
this
contract
is
more
important
than
we
realize
a
validator
is
cool,
generating
documentation
is
cool,
but
you
know
you
you
do
this
in
the
enterprise
and
people
are
wanting
to
say:
hey.
I've
got
this
source
of
truth,
this
async
api
document
or
this
open
api
document.
I
want
to
enforce
that
those
rules
and
that
contract
in
my
code,
with
this
little
code
as
possible.
A
Yeah
and
then-
and
actually
you
said
like
this
contract
is,
is
it's
really
important
right
and-
and
I
agree
with
that,
like
some
people
are
looking
at
the
open
api
and
then
kpi
files
as
as
a
documentation
as
a
way
to
document
their
their
their
apis
or
their
even
driven
architectures
or
whatever
right,
but
it's
not
just
documentation.
I
mean
to
me
like
documentation,
it's
like
a
side
effect
of
it
right.
It's
like
you,
it's
an
easy
side
effect.
That's
true!
A
That's
it's
a
something
that
you
can
generate
quickly
and
easy,
because
yeah
everything
is
defined
there
and
so
on.
But
to
me
it's
a
contract,
like
you
say
it's
a
definition.
It
can
be
used
as
a
contract
to
meet
the
definition
that
can
be
used
as
a
contract
as
a
code
generator
if
you
want,
and
and
and
also
in
in
server
frameworks,
like
you
mentioned,
like
you,
want
your
server
code
or
your
code
to
actually
your
client
code
as
well.
B
Well,
I
mean
I'm
not
surprised
that
people
think
that
way,
though,
because
remember
I
mean
swagger,
you
know
for
most
people,
especially
in
the
enterprise,
was
a
build
artifact
I
mean
most.
People
knew
swagger
is
two
things.
It
was
a
file
that
was
generated
from
their
java
code
or
their
python
or
their
javascript,
and
then
they
would
deploy
swagger
ui
the
little
web
interface
in
front
of
it
and
that
that
to
them
was
swagger.
I
mean
it
purely
was
documentation
with
a
very
lightweight.
B
You
know,
try
it
now
kind
of
feature,
and
so
you
know,
if
that's
how
most
people
knew
swagger,
which
is
exactly
how
I
started
as
well.
I'm
not
surprised
that
that
is
the
the
way
that
they
see
it,
but
there's
so
much
more
utility
in
that
document
than
just
generating
documentation
and
creating
a
you
know
a
cool
little
web
ui.
I
mean
that
is
your
contract,
because
what
you
tell
your
customer
that
their
requests
have
to
look
like
this
and
that
their
responses
have
will
look
like
this
or
need
to
look
like
this.
B
A
Okay,
yes
you're
back
cool,
so
I
was,
I
was
thinking
so
the
the
reason
I
was
mentioning
this
this
thing
about
the
server
code
is
I've
seen
that
you've
been
a
little
bit
involved
in
graphql
as
well
a
little
bit
like
probably
a
few
years
ago?
I
don't
know
if
you
continue
contributing
to
graphql
like.
Why?
Is
it
not
the
case
in
your
opinion
like?
Why
is
it
not
the
case
of
graphql
like?
Why
is
not
people
using
graphql
for
documentation?
Only,
I
have
my
opinion,
but.
B
Well,
this
is
a
case
where
I'm
going
to
defer
to
you,
because
I
haven't
done
graphql
stuff
in
a
long
time.
I
know
apigee
the
product
now
supports
graphql
for
its
api
products
and
and
some
other
features,
but
I
wasn't
involved
in
that.
So
this
is
where
you're
going
to
tell
us.
A
Okay,
so
then,
but
you
know,
graphql
okay,
you've
been
you've
been
using.
What's
what
is,
in
your
opinion
like
why,
in
your
opinion,
is
that
people
are
not
looking
at
this,
the
graphql
schema
the
same
way:
they're
looking
at
open
api
and
missing
kpi
like
they're,
not
looking
at
it
just
for
pure
documentation
or
purely
for
documentation,
like
most
people
are
doing
like.
A
B
A
I
was
saying
I
was
asking
this
because
I
I'm
seeing
the
same
trends
in
async,
api
and
open
api
and
then
on
the
we
have
like
in
one
hand,
async
api
and
open
api
and
on
the
other
hand,
we
have
graphql
and
grpc,
for
instance
right
and
in
the
case
of
graphql
and
grpc,
we're
not
seeing
people
so
much
using
them
as
documentation
generators
instead,
instead,
what
they
do
is
they
use
frameworks
that
leverage
this
files,
the
graphql
schema
or
the
protobuf
or
the
grpc
files
right
to
make
it
work
like?
A
If
you
don't
have
the
schema
and
I
think
that's
the
default
for
most
of
the
graphql
servers
like.
If
you
don't
have
the
graphql
schema
defined,
you
don't
have
an
api.
Basically,
you
cannot
make
it
work
right.
So
I
think
lately
there
are
like
some
alternatives
that
what
they
use
is
that
what
they
do
is
that
they
generate
the
graphical
schema
from
the
code,
but
at
least
how
how
I
have
I
have
been
experiencing,
the
graphql
yeah
you
know,
graphql
itself
is
that
they.
A
They
tell
you
that
you
have
to
create
the
schema
first
right,
define
all
the
queries
and
all
the
mutations,
and
then
you
go
to
the
code
and
you
link
the
queries
on
the
limitations
on
the
schema
with
your
code,
somehow,
depending
on
your
framework
right.
But
if
you
don't
have
the
query
in
the
or
the
mutation
on
the
schema
file,
then
or
it's
or
it's
something
different,
then
it
stops
working
right
like
it
stops
working
like.
B
A
Say
right
now,
what
you
see
is
that
open
api
and
sync
api,
if
you
define
a
path
with
the
post
operation,
for
instance,
and
and
then
you
have
your
code,
which
has
been
generated
from
the
open
api
file,
then
you
go
again
and
edit
the
the
open
api
file
and
remove
that
path
completely.
B
A
B
Of
that
is
because
the
I
mean
with
async
api
and
open
api.
You
know
those
are
documents
that
are
separated
from
you
know
the
server
logic
or
the
the
stack
being
used
on
the
server.
I
mean
you
know
with
graphql.
I
mean
that
is
a
server
side
thing.
So
if
you
make
a
change
to
anything
that
generates
that
file
or
whatnot
well,
then
you
know
the
api
behind
it.
Changes
with
open
api.
I
could
have
whatever
api
I
want
and
then
end
up.
B
You
know
only
you
know
describing
a
part
of
it,
but
that
doesn't
change
the
the
part
behind
it.
And
that's
that's
where,
like
I
say,
I
think
you
know,
contract
enforcement
on
the
server
and
client
with
open
api
would
be
kind
of
nice
because
you
know,
like
I
mean
you
wouldn't
have
that
problem,
but
you
know
grpc.
You
mentioned
that
and
I
think
that
that's
a
that's
a
whole
different
ball
game
I
mean
grpc
without
generated.
B
Clients
would
definitely
need
documentation,
but
grpc
is,
like
you
know:
hey
I'm
going
to
use
this
protobuf
and
I'm
going
to
generate
code
for
all
the
clients
and
for
the
servers
you
know.
If
you
don't
adhere
to
the
contract,
your
code
doesn't
compile
you
know.
So
it's
almost
like.
They
don't
need
it
as
much
because
it's
statically
typed
and
you
know
it's.
You
know
you're
using
a
ton
of
generated
code,
so
slightly
different
thing.
But
since
you
mentioned
your
pci
at
least
touch
on
it,
because
google
loves
grpc.
A
Yeah
yeah,
that's
why
I
was
mentioning
jpc
like
like
it's
a
it's
a.
I
actually
love
the
approach
that
graphql
and
jrpc
are
taking
like
they.
They
have
the
spec
and
the
code
or
the
frameworks
somehow
link
it
right.
So
you
make
them
work
together,
and
that
makes
that
makes
you
have
always
the
schema
as
a
source
of
truth
right.
So
the
spec
is
always
a
source
of
truth
for
you,
because
because
it
has
to
be
because
if
it's
not
the
source
of
truth,
then
your
code
will
behave
differently
as
well.
A
So
that
doesn't
happen
when
you
generate
code
from
an
open
api
or
an
snkpa
file
like
they
go
different
ways
and
then
yeah,
some
people
maintain
the
code,
but
they
don't
maintain
the
open
api
file
or
decision
tcp
file
right.
They
completely
abandon
it
from
and
then
at
some
point.
It's
a
mess
and
and
and
then
open
api
is
in
kpi
and
the
generated
documentation.
B
That's
why
I
said
that
the
contract
is
so
important
and
why
I
think
that
you
know
whatever
async
api
builds
and
I
would
love
to
help
out
or
be
involved,
but
whatever
path
you
go
down,
if
you,
if
you
provide
a
library
or
apis,
for
you
know,
contract
enforcement,
you
know
on
the
server
and
or
on
the
client.
You
know,
I
think
that
you
give
people
the
the
ability
to
build
tooling.
That
would
give
you
a
very
graphql
or
grpc.
B
A
B
A
So
we
got
a
question
by
the
way
we're
developing
such
a
framework,
which
is
called
lee
and
and
yeah.
So
it's
still
not
production
ready,
but
yeah
it's
getting
some
some
it's
getting
some
love.
So
we
got
a
question
from
jonas
like
what
is
your
take
on?
Why
open
api
don't
want
to
shelter
tooling
in
the
organization?
B
I'm
going
to
give
you
my
opinion
and
yes,
I
know
I
know
why
it
didn't
happen.
So
the
whole
idea
of
contributing
swagger
at
the
time
to
the
linux
foundation
was
to
make
sure
that
nobody
owned
the
spec.
But
you
know
the
code
around.
It
was
extremely
extremely
important
as
well,
because
I
mean,
if
you
can,
if
that
code,
isn't
a
part
of
the
you
know
the
open
source
community
as
well,
then
you
know
you
know:
company
x
could
see
that.
B
If
company
y
owns
the
open
api
tooling,
then
they
become
the
de
facto
and
the
standard
and
basically
any
changes
you
make.
That
code
is
contributing
to
some.
You
know
private
corporate
code
base
that's
making
them
a
bunch
of
money,
and
so
there's
a
lot
of
politics
in
it
believe
it
or
not,
but
I
think
ultimately
the
reason
why
reverb
well,
once
again,
I'm
speaking
from
my
own
opinion-
please
don't
quote
me
on
this.
You
know
was
because
you
know
the
you
know.
B
We
didn't
want
to
have
code
associated
with
the
the
open
api
organization
for
the
same
reasons,
because
you
know
if,
if
we
have
libraries
and
tools
and
code
generators
and
parsers
and
validators
that
are
a
part
of
the
open
api
linux
foundation,
you
know
organization,
you
know,
then
it
it's
not
that
it's
impossible,
but
it
basically
sets
us
up
where
to
where
we're
preferring
one
thing
or
another,
even
if
it's
indirectly-
and
we
didn't
want
to
do
that,
you
know
we
wanted
to
have
a
community
that
was
built
by
the
community
and
maintained
by
the
community,
and
we
didn't
want.
B
You
know
the
community
feeling
like
they
needed
to.
You
know,
compete
with
us.
So
if
we
provide
a
validator,
you
know
why
would
somebody
else
provide
a
validator
because
the
organization
itself
provides
validator?
That
was
my
understanding
once
again,
please,
if
I
messed
it
up,
tsc
members,
I'm
completely
sorry,
but
you
know,
like
I
say
I
mean
I
just.
B
I
think
that
we
wanted
to
separate
the
two,
because
we
didn't
want
to
make
people
think
that
you
know
we
were
trying
to
give
you
best
of
breed
tools
and
that
you
shouldn't
compete
with
us.
I
think
the
second
part
of
that
is,
would
you
want
to
have
tooling,
alongside
the
specification
work?
My
personal
opinion.
A
B
Yeah,
okay,
cool,
so
the
second
question
is:
would
you
want
to
have
tooling
alongside
the
specification
work
I
mean,
I
think
that
it
makes
sense
not
to
for
the
most
part,
because
you
know
the
reasons
that
the
tfc
took
in
the
beginning
or
the
reasons
why
reverb
like
I
say
this,
this
predates
the
tsc.
The
reason
why
reverb
didn't
want
the
code
associated
with
the
the
org
itself.
B
Their
reasons,
I
think,
are
pretty
solid,
but
I
I
personally
can
see
we're
having
reference
implementations
or
you
know,
test
suites
or
something
that
you
know
all
tooling.
Vendors
have
to
run
our
test
suite
to
be
able
to
say
hey
that
you
know
that
their
stuff
works
with
our
code.
I
could
see
that
being
useful,
but
I
don't
know
that
it
makes.
B
B
So
I
did
change
my
mind
on
that,
because
when
we
were
going
through
this
process
of
of
reverb
contributing
their
code
to
the
linux
foundation,
you
know
apogee
was
involved
in
those
conversations.
Reverb
was
the
linux
foundation.
You
know,
and
at
the
time
I'm
like
hey,
why
don't?
We
just
give
everything
to
the
linux
foundation?
This
makes
a
ton
of
sense.
B
You
know
that
way
that
nobody
owns
it,
but
you
know
the
the
conversations
that
we
had
at
the
time
were
purely
looking
out
for
the
community
and
trying
to
make
sure
that
you
know
the
community
didn't
feel
one
way
or
another
about.
You
know
the
the
open
api
organization
itself.
You
know
owning
this
code,
so
there
were
reasons
for
it
and
I
agree
with
them.
A
Yeah,
I
can
see
I
can
see
yeah,
I
hope
so
yeah,
if
not
jenna's,
feel
free
to
to
keep
bothering
jeremy.
A
A
The
context
around
them
was,
was
it
very
different
right?
So,
like
you
said,
like
smart
bear,
what
was
the
name
of
the
company
rebirth.
A
Yeah,
tony
and
volks,
I
think
right
yeah,
so
so
yes,
a
reverb
donating
this
to
to
linux
foundation,
but
they
already
had
a
business
around
it.
So
I
didn't
have
any
business
around
it
so,
and
I
made
it
clear
since
the
very
beginning
like
I
have,
I
want
to
have
the
spec
and
the
tools
in
the
same
place
right.
I
was
about
to
build
a
business
around
it.
A
Let's
be
honest
like
I,
I
was
not
to
build
it
but
to
to
try
to
start
it
right
sure,
and
but
I
I
wanted
to
make
it
clear
like
and
that's
why
I
took
this
this
direction
of
joining
jenny
and
postman
and
then
putting
things
on
the
linux
foundation.
A
So
so
things
are
safe
and
neutral
there
and
it's
not
a
postman
thing
and
people
can
contribute
there
right,
but
but
yeah
like
for
me,
the
the.
A
The
main
reason
here
is:
is
the
users
right
for
me:
are
the
the
main
reason
are
the
users.
I
know
that
it
can
be
for
some
tooling
vendors.
It
can
be
like.
Why
am
I
going
to
build
a
validator
if,
if
the
project
initiative
is
really
offering
a
validator
right-
and
that's
precisely
the
point
so
instead
of
duplicating
and
having
like
dozens
of
validators
around
you
only
have
one
and
and
the
community
can
all
contribute
to
the
same
one.
A
So
it's
open
it's
open
for
contributions,
so
all
the
community
can
help
maintain
the
official
one
right
that
doesn't
stop
you
from
building
your
own
one,
of
course,
but
but
yeah,
and
the
cool
thing
about
this
is
that
that's
all
like
rainbows
and
unicorns.
Until
until
you
have
not
people
but
businesses
around
it,
right,
yeah
and
then
people
and
when,
if
if
it's
all
done
by
people
in
their
spare
time,
that's
fine.
A
Most
people
will
agree
like
let's
unify
everything
right,
but
when
there
are
businesses
like
and
companies
are
making
money
out
of
their
implementation
and
and
and
another
company
is
doing
the
same
with
their
implementation
and
so
on.
Then
no
you
don't
want
to
unify
things
because
yeah
that
will
have
your
your
business
at
risk.
B
Yeah,
I
do
think
that
that's
you
know
that
was
there
was
some
speculation
about
that
and
there
was
even
some
concern
about
it.
You
know,
I
do
think
you
know
that's
a
common
open
source
problem.
I
mean
you've
got
you
know:
companies
standing
upon
the
shoulders
of
giants.
You
know
in
that
the
community
builds
this
really
cool
thing
and
then,
based
on
that
you've
got.
B
You
know
some
development
team
at
company
x
that
decides
to
build
some
commercial
version
of
it
and
then
now
it's
almost
like
they're
competing
with
the
open
source
version
or
whatnot,
and
it's
like
well.
If
company
x
is
bringing
in
the
library
that
the
open
source
community
works
on.
If
I
contribute
to
that
library,
am
I
effectively
and
or
indirectly
you
know
helping
that
company
make
more
money?
Well,
what?
If
I'm
a
competitor?
B
B
There's
no
question
whatsoever,
at
least
in
my
personal
opinion,
and
I
represent
nobody
else,
but
I
trust
him
and
so
I
feel
like
he
made
the
right
decision,
but
I
do
think
that
at
the
time
there
was
some
concern
or
speculation
that
you
know
the
decisions
were
made
because
the
company
buying
the
you
know
the
trademark
to
swagger.
You
know
also
had
swagger
tooling
and
that
they
basically
built
on
top
of
the
open
source
stuff
and
it's
very
easy
to
go
down
that
path.
B
But,
like
I
say
I
mean,
if
you
look
back
at
the
way
tony
handled
this,
he
was
definitely
community
first
and
and
like
I
say
I
mean
I,
I
agree
with
his
his
reasoning
so
but
yeah
I
mean,
I
think,
any
time
you
work
in
the
open
source
community
and
you
provide
value.
There's
going
to
be
some
company,
that's
going
to
try
to
provide
more
value
than
you
do
and
make
money
off
of
the
stuff
that
you've
done
and
that's
just
that's.
The
open
source
model
there's
no
way
around
it.
A
Yeah
yeah
now
I
agree
like
I.
I
completely
understand
tony's
decision
here,
so
I
will
probably
have
done
the
same
thing.
You
have
investors
as
well
and
you
have
a
company.
You
have
a
business
to
to
keep
to
keep
running,
so
you
cannot
donate
the
whole
swagger
tools.
You
know
all
the
tools
around
the
swagger
specification
to
a
new
foundation
that
you're
creating
or
project
that
you're
creating
in
the
linux
foundation.
A
B
A
Will
be
a
suicide
probably
or
a
business
suicide?
I
mean
you
never
know,
but
it's
very
risky
sure,
but
but
yeah
like
and
that's
that's
why
I
would
say
like
they're,
both
coming
from
different
sources.
Origins
right.
So
so
we
were
a
little
bit
more
free
to
take
this
decision
because
there
was
no
business
around
it.
No.
A
A
B
I
can
see
them
going
both
ways.
I
see
the
value
in
both.
I
see
you
know
the
open
api
or,
let's,
let's
not
even
make
this
about
the
open
api.
Specifically,
you
know
spec
community,
x
or
spec
owner
x,
linux
foundation.
I
can
see
there
being
benefit
and
then
providing
some
like.
I
say
reference
implementation,
some,
you
know
test
suites
or
test
kits.
B
You
know
100,
and
I
think
that
you
know
there
is
also
a
level
of
trust
that
you
get
when
the
the
the
spec
community
itself
provides
tooling
because
you're
like
hey,
you
know
random
developer
x.
Has
this
library-
or
you
know
the
people
that
maintain
the
thing?
Have
this
library?
You
know
it's
like.
I
feel
like
there's
a
level
of
trust
and
value
expected
out
of
the
one
that
the
k
that
the
the
project
owner
maintains
than
what
you
would
get
from
someone
else.
Now,
that's
not
to
devalue
what
this
other.
B
You
know,
random
developer
may
do,
but
I
do
think
that
you
know
when
someone
wants
to
build
around.
You
know
a
technology,
you
know
be
it
open
api.
I
mean
you
can
go
to
google
and
look
around
and
it's
like.
Well
what
do
I
choose,
and
why
would
I
choose
it,
and
you
know
I
think
that
you
know
if,
if
you
had
tooling
and
libraries
from
the
the
the
community
owner-
or
you
know
the
project
owner
or
whatnot,
that
I
think
that
it
carries
some
weight,
but
I
think
one
reason
why
tony
was
against.
B
So,
like
I
say
I
can
see
the
flip
side
as
well,
but
one
thing
that
the
open
api
did
do
is
I
think
that
there
is
a
pro
there's,
a
site
called
open
api.tools
where
you
can
go
register
known
tools
and
they've
got
like
a
functionality
graph,
where
you
can
say
it
works
with
1.x,
2.x
3.x.
B
You
know
what
languages
it's
in
and
things
like
that
to
help
bridge
the
gap
and
getting
into
that
list
is
I
mean
it's
gated
in
that
it's
maintained
by
you,
know
tsc
members,
or
at
least
a
tsc
member,
but
you
know
I
don't
know
to
what
extent
you
know
it
the
difficulty
it
takes
to
get
on
there.
You
know,
I
think
I've
got
a
couple
of
my
things
on
there,
but
I
mean
I
I
can
see
both
sides.
I
can
see
both
sides.
I
know
why
tony
did
what
he
did.
B
See
where,
as
a
consumer,
where
I
would
feel
some
level
of
comfort
knowing
that
the
people
that
know
this
better
than
anybody
are
providing
me
with
tools
and
libraries,
and
if
I
don't
like
them,
I
can
still
build
my
own,
but
they
give
me
something
I
feel
like.
I
could
trust
so
I'm
on
the
fence,
I'm
on
the
fence
yeah
even
now,.
A
I
mean
that's,
that's
that's
that's
okay,
like
and-
and
I
want
to
remind
everyone
again
that
you're
representing
yourself
not
open,
ebay,
tse
or
google
right,
like
you're,
representing
jeremy
whitlock,
and
that's
it
and
and
I'm
asking
for
your
opinion,
since
you
have
this
experience
here.
So
please
don't
take
his
opinion
as
the
open
api,
tsc
opinion
or
google's
opinion
right.
People
tend
to
do
these
things
very
easily,
so
so
yeah.
B
Money
will
also
elaborate
or
ask
more,
I
think,
what
you're
doing,
if
you're
asking
for
me
to
validate
what
you're
doing,
I
think
what
you're
doing
makes
sense.
I
mean
I,
like
I
say:
whenever
we
first
started:
building
open
api
tooling,
we
tried
to
throw
as
much
into
our
stuff
as
possible
that
way
that,
as
apogee
built
a
name
for
building
good
quality,
open
api,
tooling.
A
B
We
were
speaking
at
conferences
and
doing
everything
we
could
to
be
known
as
one
of
the
leaders
at
that
time.
You
know,
you
know
we
didn't
contribute
our
stuff
back
to
you
know.
You
know
reverb
at
the
time.
I
think
a
couple
of
the
projects
we
did
or
one
of
them
we
did.
I
think
it
was
called
swagger
editor
or
something
like
that.
But
you
know
we
kept
our
own
stuff
too,
and
I
think
for
you,
you
know,
for
you
not
being
you
know,
backed
by
you
know
a
corporation
or
a
company.
B
You
know,
I
think
you
know
the
approach
you're
taking
makes
sense
to
me
because,
like
I
say,
I
can
see
both
sides
from
an
open
api
perspective
and
there's
history
that
makes
it
you
know
that
muddies
the
waters
a
little
bit,
but
you
don't
have
that
history,
you
don't
have
muddy
waters.
Your
thing
is
look.
B
I
want
to
have
a
spec
and,
as
the
author
of
that
spec,
I
want
to
provide
some
best
of
breed
tooling
and
libraries
that
people
can
gain
value
from
immediately
and
if
they
decide
that
it's
not
good
enough
or
they
want
to
do
something
better,
they
can
either
contribute
back
to
the
the
single
source
of
truth,
or
they
can
go,
do
their
own
thing
and
I
think
that's
exactly
how
all
communities
could
could
be.
But,
like
I
say
with
with
swagger,
you
know
coming
from
where
it
did.
B
You
know,
basically
being
created
and
owned
by
a
private
company
for
a
while
and
then
being
sold,
are
parts
of
it
being
sold
to
the
private
company
and
the
spec
itself
being
contributed
to
the
linux
foundation.
I
just,
I
think,
there's
a
there's
a
lot
of
history
and
muddiness
that
you
don't
have
to
deal
with.
So,
if
you
don't
have
to,
I
think,
having
hey
this
guy
wrote,
this
thing
he's
got
some
tools,
I'm
gonna
use
those
I'm
gonna,
trust
those,
and
that's
where
I
would
go
first
before
I
went
anywhere
else.
A
So
no
I
I
I
agree
like
it's
all
about
the
context
right,
but
we're
not
coming
from
the
same
context
and
the
same
history.
So
we
don't
have
the
same.
We
share
a
big
chunk
of
the
spec
is
shared,
but
but
the
history
is
not
right.
So
so
that's
that's
why
we
took
this
decision
to
to
make
it
to
make
it
all
in
one
right.
A
Everything
is
on
the
on
the
foundation
on
the
project
and
and
yeah,
and
people
can
still
decide
to
build
their
own
tools
and
we
will
be
happy
to
list
them
on
the
website
as
well
like
we.
We
tell
them
like
hey
it's
not
just
that
we
build
our
tools
and
or
you
can
build
your
your
own
tools,
but
you
can
also
list
them
on
our
website.
A
So
people
know
that
there
there
are
alternatives
to
the
official
ones.
If
you
want
sure
so,
yeah
like
we
have
no
business
intention
or
ownership
intention,
like
everybody,
should
come
with
us
right
like
no.
No,
let's,
if
there's
something
better
out
there
go
with
that
right.
So
so
it's
there
and
now
and
we'll
try
to
help
you
find
in
there.
So
so
yeah
awesome.
So
one
thing
coming
back
to
the
topic
of
departures
and
and
and
sdks
and
so
on.
A
So
there
is
a
problem
if
you
want
to
call
it
like
this,
that
I've
been
noticing
during
the
years-
and
it
said
every
time
open
api
is
launching
releasing
a
new
version,
especially
if
it's
a
major
version,
it's
struggling
with
adoption
from
the
tool
inside
right,
so
that
tooling
is
slow
at
like.
I
understand.
B
A
So
and
then
we
and-
and
I'm
just
I
I
I
mean
I've-
been
also
in
this
conversation
for
a
while
with
you,
I
mean-
maybe
not
with
you,
but
with
the
with
daryl,
with
you
know,
with
ron
and
folks
like
how.
How
can
we
improve
this
or
how
can
yeah
you
improve
this,
because
I'm
not
participating
on
the
open
apa
development
but
but
yeah
like.
I
would
like
to
to
know
like.
B
I
think
in
this
case,
ironically,
it's
one
of
those
cases
where,
if
the
open
api,
tsc
or
the
organization
itself
or
develop,
were
delivering
tooling,
I
think
that
would
help
out
a
ton.
You
know
so
I
mean
like
I
say
where
you
have
a
reference
implementation
or
a
test
kit
or
test
suite.
You
know.
I
think
that
that
would
be
something
that
could
be
useful
because
you
know
a
lot
of
these
features
that
come
out.
You
know
I
know
going
from
2.0
to
3.0
is
a
big
change.
B
You
know,
3.0
is
a
superset
and
I
think
for
all
the
tooling
I've
ever
written
and
and
integrated
with
from
an
open
api
perspective.
You
know,
3.0
didn't
add
a
lot
in
my
opinion
that
that
made
me
want
to
update
my
tools
and
not
only
that
it
was.
You
know
there
were
a
lot
of
things
now
where
it's
like.
You
could
describe
your
your
requests
and
responses
in
in
multiple
ways
or
features
that
don't
really
have
a
good
need,
and
let
I
mean
unless
your
api
needs
it.
B
You
know
links
and
hypermedia
and
stuff
like
that,
like
I've
never
got
on
a
hypermedia
train.
So
for
me
it
was,
you
know,
updating
my
tools
for
that.
It
wasn't
as
important
to
me,
but
you
know,
I
think
I
mean
I
think,
that's
where
there
may
be
a
potential
disconnect
with
open
api,
the
tsc
and
the
the
organization
and
the
community
as
a
whole.
You
know
by
not
providing
tooling
or
at
least
reference
implementations
of
tooling.
B
You
know
it's
because
we
throw
out
a
spec
and
say:
hey,
you
know:
hey
jeremy,
you
have
this
really
cool
library
called
sway
and
it
does
all
the
things.
If
I
were
to
build
something
for
a
swagger,
2.0
or
open
api
2.0
sway
is
awesome.
You
could
build
middleware
code
generators,
everything
well
to
go
from
2.0
to
3.0.
It's
like
all
right.
Well,
you
know
I
just
didn't
have
the
time
to
do
it
myself.
I
can
tell
you
why
I
didn't
do
it.
B
You
know
sway
was
developed
partially,
while
working
at
apogee,
and
then
you
know
the
majority
of
it
was
done
on
my
own
time
and
I
was
one
person
and
when
3.0
came
out
I
think
stoplight
and
some
other
companies
were
creating
their
own
parsers
and
validators.
Instead
of
contributing
to
mine.
I
don't
care
how
it
happens,
but
I
can't
compete
with
a
team
of
people
getting
paid
to
do
it
and
I'm
doing
it
on
my
own
time
and
I
got
burned
out.
I
didn't
want
to
look
at
my
laptop
at
night.
B
So
that's
what
happened
with
me,
but
I
think,
as
far
as
like
the
tsc
or
open
api
trying
to
help
out
you
know
there
is
no
good
way
right
now
to
know
what
changed
between
versions
and
I
think
that
that
would
help
out
quite
a
bit.
I'm
not
I
mean
I
think
we
do
have.
I
mean
we
do
have
release
notes
that
help.
You
understand
some
things,
but
you.
A
B
Think
if
I,
if
I
have
a
tool
that
supports
3.0
and
we
release
3.1,
you
know
for
my
tool
to
be
updated.
I
really
need
to
know
the
delta
of
those
changes
so
that
I
can
update
my
tool-
and
I
don't
know
I
mean
this-
this
could
be
a
place
where
your
approach
may
work
better
for
for
the
community,
where
you
know
before
you
release
a
new
version
of
your
spec
you're,
going
to
update
your
tooling
to
work
with
that
spec.
A
B
So
you're
kind
of
you
know
leading
tool
authors
by
design
or
by
example,
and
the
open
api
doesn't
have
that
right
now
we
release
a
new
version
of
spec.
We
release
the
release
notes,
but
since
we
don't
maintain
any
tooling,
we
don't
have.
The
onus
on
us
to
you
know
go
through
the
work
and
effort
a
tooling
offer
author
would
have
to
do.
You
know
what
I
mean
and
and.
A
B
That's
where
a
lot
of
my
contributions
to
the
tsc
have
come
from.
You
know
I
I'm
not
the
most
active
member,
I
mean
I'm
super
busy
with
other
things
at
work,
but
you
know
I,
I
am
still
heavily
active
and
a
lot
of
my
pushback
or
questions
or
concerns
have
typically
come
from
the
perspective
of
a
tooling
author,
because
I
know
the
amount
of
work
it
takes
to
build
these
things,
and
I
don't
know
that
we
as
a
tsc
do
much
to
help
tooling
authors
beyond
just
authoring
the
spec
and
providing
release
notes.
A
Just
want
to
make
something
clear
like
I'm,
so
I'm
not
asking
you
for
like
what
will
you
do
from
the.
A
We
know
like
open
api
is
not
maintaining
tool
tools.
So
that's
that's,
okay.
You
cannot
touch
there,
but
but
I
was
more
interested
in
the
in
in
your
private
side.
Let's
say
on
your
own
side
of
things
like
you're,
building,
a
a
parser
and
a
validator
or
something
or
an
sdk,
to
work
with
open
api
too,
let's
say,
and
then
you
have
to
update
to
open
the
pa3
and
then
open
open
api
3.1
right,
which
okay,
as
some
may
already
know
it
has
like,
could
be
a
yeah.
A
I
think
it's
a
breaking
change
but
yeah,
but
might
not
not
be
considered
strictly
as
a
breaking
change,
so
yeah,
but
it's
it's.
It
has
an
important
change
which
is
basically
on
json
schema
right
on
on
the
adoption
of
the
newer
json
schema.
So
if
you
had
to
on
your
side,
let's
sway,
you
have
all
the
time
you
can
dedicate
to
this,
like
what
will
you
do
to
make
your
parser
or
your
tools
as
easy
to
be.
A
Upgraded
to
newer
versions
of
open
api
as
possible
right,
so
so
that
people
specifically
so
that
people
can
still
use
sway,
but
without
having
a
breaking
change
on
their
side.
Okay,
I
mean.
B
Well,
I
kind
of
went
through
some
of
this
and
don't
tell
anybody.
I
say
that
jokingly,
but
I
actually
have
a
version
of
sway
that
works
with
3.0
on
my
laptop.
I
just
needed
to
fix
it,
but
I
I
may
release
it
at
some
point,
but
I
think
for
me,
what
I
had
to
do
go
you
know
was
to
take
an
approach
that
it
sounds
like
what
you're
talking
about,
which
is
basically
abstract
my
api
from
the
spec.
You
know
I
created
my
own
objects
that
define
you
know.
B
I've
got
a
an
api
document
and
then
I've
got
operations
and
paths,
and
all
I
mean
I
basically
tried
to
figure
out
some
way
to
create
a
programmable
model
that
you
know
I
could
hide
the
json
schema
behind
it.
I
could
hide
the
changes
of
you
know
where
it's
coming
from
you
know,
so
you
know
with
3.0
you
could
you
could
define
examples.
You
know
in
multiple
ways
you
could
define
response
objects
in
multiple
ways,
and
you
know
abstracting
where
that
comes
from
or
where
it
was
defined.
B
You
know
was
a
huge
win,
so
I
think
the
first
thing
that
I
you
know
had
to
do
and
and
would
suggest,
would
be
figure
out
some
way
to
separate
the
programming
model
that
you're,
creating
and
exposing
to
your
tool,
your
your
consumers,
you
know
away
from
the
actual
specification
itself
and
you
know
that's
easier.
I
mean
it's
actually
not
as
difficult
as
it
may
seem,
but
that's
that's
probably
the
biggest
thing
you
know
that
I
can
think
of.
Is
you
know
the
spec
is
going
to
change.
B
You
know
as
features
are
added
or
breaking
changes
happen
you're
going
to
end
up,
you
know
with
3.0.
Like
I
say
for
me,
it
was
a
huge
breaking
change
because
of
the
way
that
we
now
had.
You
know
different
ways
to
do
the
same
stuff,
and
that
was
the
biggest
problem
that
I
had
to
solve.
Was
you
know?
How
can
I
provide
an
api
that
that
makes
sense
to
somebody
list
me
all
operations
validate
this
request?
B
A
B
Needs
that
you
know,
needs
the
the
validate
request
or
validate
response,
so
you
know
abstracting.
That
is
probably
about
the
only
way
that
you
can
that
you
can
do
such
a
thing
and
of
course,
that
comes
at
a
cost
behind
the
scenes
of
you
know
some,
I
wouldn't
say
ugly
code,
but
you
basically
end
up
with
a
plug-in
model
or
some
sort
of
a
way
to
you
know
to
you,
know,
pick
and
choose,
and
you
know
then:
you've
got
library,
size
issues
because
you
got
to
ship
with.
B
A
Yeah,
exactly
the
user
intents
are
not
going
to
change.
The
people
will
want
to
do
whatever
they
want
to
do
independently
of
the
version
of
your
spec
like
exactly
and
then,
and
especially-
and
this
is
especially
annoying
when
you
get
a
new
major
version
where
you
can
still
do
what
you
used
to
do,
but
in
a
different
way
right,
like
from
that
happened
from
swagger
2
to
open
the
pa
3
and
that's
about
to
happen
from
async
api
2
to
sync
3..
A
So
yeah,
that's
about
to
happen
like
we're
reorganizing
the
spec
around
just
that
reorganizing
it
for
future
development,
but
you
will
you'll
still
be
able
to
to
do
whatever
you're.
You
know,
you're
currently
able
to
do,
but
in
a
different
way,
and
therefore
it's
a
breaking
change
right
on
the
spec
side.
But
on
your
you
know,
on
the
consumer
side,
it
shouldn't
be
a
breaking
change.
If
I
want
to
list
all
the
messages
in
the
document
just
yeah,
why
so?
It
doesn't.
A
I
don't
care
just
give
me
the
message
just
give
me
the
messages
give
me
all
the
operations.
Give
me
all
the
I
don't
know
schemas
like
I
don't
know
how
these
schemas
are
defined.
I
don't
care
because
that's
your
problem
as
a
as
a
as
a
partial
right
or
sdk
right
to
abstract
this
away
and
then
give
it
to
me
in
a
in
a
specific
format
right
and
specific,
well,
jeremy.
Actually,
one
hour
right
now
is
there
anything
you
would
like
to
add
before
we
close
it.
B
No
man,
I
really
appreciate
you
giving
me
the
chance,
my
first
ever
podcast.
Hopefully
I
did
okay.
You
know
I
had
a
good
time.
I'm
surprised
there
weren't
more
questions,
but
I
mean
maybe
it's
a
topic
that
most
people
know
very
well.
Who
knows
yeah,
that's
a
good
thing.
I
appreciate
it.
A
No
problem,
actually,
I
think,
is
it-
was
really
really
cool
for
being
your
first
times
so
yeah,
congratulations!
It
was
a
good.
B
A
B
It
might
have
even
been
rotten,
it
was
either
ron
or
my
buddy
adrian,
but
you
know
I
was
speaking
on
something
and
every
time
I
would
speak.
I
had
a
lot
of
filler
words
and
you
know
and
things
like
that,
and
I'm
not
say
I
don't
know
how
I
did
today.
I
didn't
even
pay
attention,
but
I
just
remember
the
first
time
I
ever
had
a
speaking
engagement.
I
was
sweating
so
bad.
A
Yeah,
thank
you.
I'm
happy
that
you
felt
comfortable
today
so
yeah.
So
thanks
everybody
for
watching
and
thanks
jeremy
for
joining
me.
If
you
have
any
further
questions
or
comments,
you
know
jeremy's
on
twitter
as
well,
and
you
can
comment
on
the
on
the
twitter
thread
that
I
already
created
for
this
or
just
yeah,
have
a
chat
with
him
online.
He
is
a
I'm
sure,
he's
available,
so
anytime
cool
folks
see
you
all
bye-bye
have
a
good
one.