►
Description
Continuing on the journey of building a new API platform, NAB’s primary focus this year has been improving API quality by building tooling for API design and API governance. This Kong Summit 2020 session will cover NAB’s new API search capability, which allows quick API discovery across the organization, and how the team implemented decentralized API governance.
A
Hello:
everyone
welcome
to
the
kong
summit
2020.
thanks
for
joining
me
in
the
session.
My
name
is
gaurav
verma
and
I'm
a
principal
engineer
at
nab.
Today,
I'm
going
to
be
talking
about
decentralizing
api
design
and
how
we
are
making
the
api
design
process
more
collaborative
at
now.
Hope
you
guys
enjoy
the
session
so
that
you
guys
don't
get
distracted
by
my
pretty
face.
I'm
just
going
to
hide
behind
this
gorilla
and
I'll
see
you
guys
back
at
the
question
answer
session.
B
B
B
So
today,
I'm
going
to
talk
about
some
of
the
tools
that
we
have
built
in-house
to
conquer
these
challenges
and
some
of
the
reasons
on
why
we
had
to
build
custom
tools.
So,
let's
start
with
a
quick
overview
of
the
platform,
we
call
it
a
cloud
agnostic,
sas
platform
for
api
management,
it's
a
multi-tenanted
platform
and
you
can
think
of
it
as
something
similar
to
the
amazon
api
gateway,
but
is
available
on
amazon,
azure
and
openshift
for
on-premises
workloads.
B
B
This
is
the
kong
data
and
control
plane
and
is
run
simply
and
as
a
tenant
of
the
platform.
You
don't
need
to
care
about
how
to
install
kong
and
how
to
upgrade
it.
And
how
do
we
scale
up
and
scale
down
across
the
all
these
clouds?
How
do
we
patch
voices?
None
of
that
you
need
to
take
care
of
all
that
is
taken
care
by
a
central
team.
All
you
need
to
do
is
use
the
cli,
which
is
the
next
tool
in
the
tool
chain
and
use
it
to
deploy
apis.
B
B
B
B
B
B
All
you
need
to
do
is
define
your
open,
eps,
spec
and
add
a
custom
annotation,
which
is
called
x,
facts
down,
define
all
a
gateway
configuration
within
that
custom
annotation.
So,
in
this
case,
we
have
defined
some
code
and
some
rate
limiting
and
once
you've
done,
that
you
pass
the
open
api
spec
to
the
cli
which
deploys
it
to
the
runtime
and
as
part
of
the
same
process.
It
also
publishes
the
api
to
the
portal.
B
B
We
also
captured
a
lot
of
metadata
as
part
of
this
publishing
process,
so
the
api
version
is
captured,
which
team
was
deploying
was
captured,
which
environment
was
it
being
deployed?
To
is
another
thing
we
capture
what
was
the
gateway
type
and
all
this
metadata
will
help
us
immensely
when
a
consumer
comes
to
discover
that
api,
as
we
will
see
very
soon
so
now,
an
api
consumer
comes
along
and
thinks.
How
do
I
find
an
existing
api?
B
B
Now
as
an
api
consumer,
if
you
want
to
narrow
your
search
down
to
a
specific
team
or
category
your
gateway
or
api
status
environment,
you
can
do
that
by
clicking
on
the
open
filters,
button
and
filling
one
of
these
fields
in
so
in
this
case,
I've
filled
in
open
banking
and
now
I'll
only
be
seeing
apis
from
open
banking.
So
when
I'll
do
the
search,
it's
only
going
to
search
through
apis,
published
by
the
open
banking
team
on
to
the
main
search
functionalities.
B
So
all
you
need
to
do
is
start
typing
in
the
main
search
box
and
the
table
immediately
starts
filtering
based
on
the
search
query
and
the
filters
that
you
have
selected
in
this
case.
I've
typed
in
builds-
and
I
now
can
see
two
apis
that
have
builds
in
their
titles.
Now.
If
I
click
on
the
first
one,
I
will
be
taken
to
a
details
page
for
that
api.
B
But
now,
let's
move
on
to
the
business
end
of
this
talk
on
how
we
are
making
api
design
more
collaborative.
So
here
we
see
all
the
states
and
api
can
take
at
nab
and
the
workflow
for
an
api,
as
it
goes
through
its
life
cycle
phases
of
design,
build
and
run
for.
The
purpose
of
this
talk
we're
going
to
focus
on
the
design
phase
and
we're
going
to
quickly
talk
about
each
of
the
states
and
their
significance.
B
So,
let's
dive
in
with
the
drought
state,
any
new
api
created
is
created
in
the
draft
state.
The
only
check
we
do
at
this
stage
is
the
api
should
be
unique
within
the
namespace
and
we
do
the
uniqueness
check
using
the
api
title.
The
api
can
contain
errors
at
this
stage
and
does
not
have
to
meet
the
nav
api
standards
moving
to
candidate
state
things
get
a
little
bit
more
interesting
and
difficult
in
order
to
move
any
api
to
the
candidate
state.
B
The
api
must
be
a
valid
open
api
specification
and
also
meet
all
lab
api
standards.
Once
the
api
is
ready
for
review,
it
can
now
be
moved
into
a
needs
review
state
which
gives
ability
to
other
team
members
to
review,
comment
and
request
changes
to
the
api.
The
experience
is
very
similar
to
github
review
process.
Also
during
the
review
api
champions,
which
is
a
select
group
of
api
ninjas,
can
request
api
changes
across
all
teams,
so
team
members
usually
can
only
view
apis
within
the
team,
but
api
champions
can
review
apas
across
any
team.
B
I
click
some
buttons
and
get
onto
this
create
new
api
screen.
All
I
need
to
do
is
fill
up
an
api
title.
It
has
to
be
unique.
The
version
because
it's
a
new
api
is
always
going
to
be
1.0.
I
need
to
select
a
category
out
of,
I
think
120
categories
we
have
if
I
have
an
existing
open
api
spec
that
I
have
created
outside,
I
can
import
it
by
using
this
field
here.
B
B
All
the
apis
for
a
specific
team
are
listed
along
with
all
the
necessary
information
of
what
version
they
are
in
and
what
state
they
are
in
and
are
they
compliant
or
not
to
the
nav
api
standard
and
open
api
spec,
and
if
they
are
not
compliant,
you
cannot
move
them
to
the
candidate
state,
however,
as
and
when
it
does
become
compliant.
Its
state
can
now
be
changed
from
draft
to
candidate,
using
this
drop
down.
B
Now,
after
making
some
more
interesting
changes
to
the
api
in
the
candidate
state,
we
are
now
ready
to
trigger
the
peer
review
process.
In
order
to
do
that,
we
need
to
select
the
needs
review
state
from
the
drop
down
which
opens
up
the
start
review
screen
on
this
screen.
You
select
some
of
your
team
members.
You
can
select
all
of
them
if
you
like,
but
you
at
least
have
to
select
one
and
press
submit
to
kick
start
the
review
process.
B
When
a
user
clicks
on
this
link,
they
are
taken
to
the
screen,
which
is
the
review
changes
screen,
and
there
are
two
tabs
in
here.
One
is
the
changes
tab,
which
is
this
one,
and
what
you
see
here
is
a
diff
viewer.
So
when
there
are
two
versions
of
an
api,
compare
you'll
see
the
diff
between
the
versions.
B
B
On
the
right
hand,
side
you'd
see
the
name
of
the
requester
who's
asked
for
the
review
or
requested
the
review,
and
then
you'd
see
a
list
of
reviewers
and
whether
they
have
requested
changes
or
accepted
the
change
or
approved
the
change.
Then
you'd
see
a
list
of
api
champions
who
have
requested
or
approved.
The
change
review
can
only
be
marked
complete
if
no
one
has
requested
changes
to
the
api,
and
at
least
one
person
has
approved
the
changes
once
the
review
is
completed.
B
B
There
is
one
last
thing
that
I
would
want
to
talk
about
today,
and
that
is
something
that
has
troubled
us
for
a
very
long
time,
and
probably
some
of
you
guys
would
be
in
the
same
boat
as
us.
So
it's
I
thought
it's
important
to
discuss
this
and
and
the
question
is
that:
are
we
reinventing
so
when
we
already
have
github
in
confluence
within
the
bank
and
we
could
buy
off
the
shelf
products
like
swagger
and
stoplight?
B
So
the
first
group
of
tools
is
confidence
in
github
and
we
already
had
these
tools
in
nab
and
what
these
tools
are
great
at
is
workflow,
so
both
those
tools
can
do
workflows.
Github
you
by
default,
get
workflows
confidence.
You
can
do
that
via
plugin
and
that's
great.
However,
these
tools
are
not
great
at
discovery
and
governance,
so
there
is
no
way
for
us
to
enforce
teams
to
push
all
their
apis
into
one
conference
space
or
one
github
repository.
B
B
The
other
group
of
tools
that
we
looked
at
was
swagger
have
been
stoplight,
and
these
tools
exist
for
api
design
and
they're
really
great
tools,
so
you
can
do
discovery
in
them.
You
can
do
governance.
Apis
are
the
reasons
they
exist,
so
you
can
track
some
metadata
in
there,
but
what
we
really
found
that
they
did
not
support
any
workflows
and
workflows
was
very
important
for
us
and
that's
something
we
really
wanted,
and
the
reasoning
was
that
we
wanted
to
start
measuring
the
cycle
time
of
apis.
B
B
The
other
thing
we
found
was
these
could
not
track
metadata.
Like
environments
teams
categories,
we
had
a
lot
of
them
so
yeah
they
couldn't
track
that
sort
of
metadata
and
they
couldn't
detect
breaking
changes.
So
if
teams
or
someone
by
mistake,
changed
a
path
and
pushed
the
same
version
of
the
open
api
spec,
they
wouldn't
push
back
saying:
oh
hey!
You
should
probably
want
to
bump
up
the
version
and
we
found
that
some
teams
were
doing
that.
So
we
really
wanted
to
make
sure
that
that
does
not
happen.
B
B
We'd
also
want
to
extend
this
to
a
model
registry
where
the
api
design
experience
will
start
from
actually
designing
your
models
first
and
the
same
could
be
in
future,
extended
to
avro,
schema,
protobufs
and
so
on.
So
that's
the
primary
reason
for
us
building
this
custom.
We
saw
a
lot
of
benefit
for
apis,
but
then
we
also
saw
benefits
that
would
help
us
conquer
the
challenges
in
future.