►
From YouTube: Discover and expose APIs securely with Gloo Gateway
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
A
This
platform
actually
comes
with
an
amazing
developer
portal
and
in
this
video,
we're
actually
going
to
start
by
exposing
the
applications
API
securely.
We
have
this
product
page
service
running
and
we
are
going
to
annotate
the
service
of
the
product
page,
to
tell
the
platform
where
to
find
the
open,
API
dock
as
well
as
your
spec.
You
can
see
we
give
the
URL
for
finding
the
spec,
but
it
can
just
be
specifically
a
path
like
slash
swagger.yaml,
then,
in
that
case,
we'll
it'll
just
look
at
this
path
on
the
service
itself.
A
A
You
see
the
service
in
this
case
is
actually
the
product
page
service
in
the
namespace
in
cluster
one,
and
this
is
the
spec
itself.
Every
time
the
deployment
is
going
to
be
rolled
out,
it's
going
to
update
this
API,
because
when
you
restart
your
pod,
that
means
that
potentially,
you
have
a
new
version
of
this
API.
A
You
can
also
see
later
that
you
can
also
create
this
API
doc
manually
by
providing
this
information
instead
of
having
it
discovered,
which
is
useful
when
it's
an
external
service,
we
have
this
API
doc
discovered.
Now
we
want
to
expose
it.
So
again
we
use
a
route
table
like
we've
done
previously
for
all
other
applications,
and
we
are
just
going
to
add
this
portal
metadata,
which
is
not
going
to
be
used
now,
but
we
are
going
to
take
advantage
of
it
a
little
bit
later
on.
A
Then.
What
we
need
to
do
is
we
need
to
expose
these
apis
through
a
prefix
API
book
info,
but
really
or
in
reality
the
back
end
is
expecting
API
B1
of
product.
We
use
this
path
rewrite
to
make
sure
that
the
backend
service
is
going
to
receive
the
request
with
the
right
path.
Then
we
apply
some
labels
as
well,
because
we
want
to
secure
the
requests
with
API
keys
and
we
also
want
to
apply
some
rate
limiting
there.
We
also
want
to
use
some
transformation
later
based
on
this
API
product
page.
A
A
A
I'm
going
to
specify
the
x-dot
server
that
I
want
to
use
again.
I
just
have
one
x
dot
server,
because
that's
what
people
generally
do
in
in
their
environments.
Now,
if
I
have
to
try
to
access
the
API
like
it
did
before,
I
get
a
401,
because
the
API
key
has
not
been
sent,
and
that
implies
that
I'm
not
authorized
to
send
this
request.
A
A
So
we
are
now
going
to
create
rate
limiting
based
on
this
x
solo
plan.
The
Xolo
plan
header
has
a
value
gold.
In
my
case,
we
are
going
to
create
this
descriptor
key
usage
plan
based
on
this
header.
Let's
take
this
and
create
a
policy
so
that
we
say
we
want
to
apply
a
limit
of
five
requests
to
the
users
that
have
this
plan
set
to
gold.
At
the
moment.
A
But
we
have
different
limits
for
different
plans,
so
this
can
be
very
useful,
especially
when
it
comes
to
billing.
Instead
of
doing
a
per
a
billing
per
request
or
a
per
billing
request,
which
is
something
you
can
do,
we
can
speak
about
monetization
inside
of
another
video.
Here
you
can
do
a
very
simple
billing,
which
is
you
choose
the
plan
you
have
for
different
pricing
for
either
bronze
silver
and
or
gold.
A
Based
on
your
requirements,
you
can
send
some
requests
until
you
reach
a
limit
and
that's
a
pretty
popular
way
to
do
billing
inside
of
the
API
world.
Let's
apply
this
again
and
you
can
group
everything
everything
together
in
this
ready-made
policy
and
say
you
want
to
do
this
after
authentication,
because
you
want
to
take
advantage
of
this
X
User
plan
that
is
created
by
the
xdoc
policy.
Then
what
you
can
do
is
Define
your
rate
limit
server.
A
Again,
we
only
have
one
and
that's
what
like
I
said:
people
generally
do
because
it's
flexible,
you
can
have
many
if
you
want
to
and
that's
fine
I
can
try
to
send
this
request
10
times
providing
the
API
keys
so
that
my
user
is
correctly
authenticated
and
I
should
see
some
200
responses
at
the
beginning.
Then,
after
five
seconds,
I
should
start
to
see
for
29s,
which
you're
able
to
see
and
after
five
successful
requests,
then
I
am
basically
rate
Limited.