►
From YouTube: 20180425 - API Management Working Group Meeting
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
B
B
B
B
So
what
we
have
here
is
what
we
call
a
product,
an
API
product
and
I,
just
created
a
hello
world
product,
so
yeah
I
should
point
out
that
do
need
an
AB
G
account
to
actually
make
this
work,
but
you
can
sign
up
for
one,
that's
quite
easy.
So
what
we
have
here
is
when
you
create
a
product,
you
are
creating
an
API
that
is
going
to
be
used
in
you
know.
Whatever
way
you
want
to
use
it.
B
Basically,
it's
associated
with
an
application
and
a
developer
and
I'll
show
you
that
in
just
a
second
but
I
guess
I
guess
the
easiest
way
to
describe
it
as
the
the
product
is
actually
we're
outside
of
outside
of
very
specific
proxy
policies
that
you
can
write
that
work
in
line
in
Apogee
in
the
full
Apogee
thing.
This
is
where
you
would
set
the
basics
of
who
has
access
to
what
and
what
the
quotas
are.
B
Okay,
this
the
way
it
matches
this.
It
says:
okay,
give
me
what
service
we're
going
to
the
target
service
and
that's
you
know
in
this
list,
and
it
is
a
list
leaving
the
comma
delimited
and
then
it
also
checks
the
pads
and
make
sure
that
the
path
is
okay,
so
you
can
set
up.
You
know
a
range
of
things
and
the
scope,
so
all
of
these
things
have
to
match
for
this
product
to
take
effect
on
that
request,
and
so
you
can
set.
B
You
know
multiple
products
in
different
ways
for
this
kind
of
thing,
the
developers
not
very
interesting.
It's
just
the
you
know
user
ID,
but
the
app
is
a
little
bit
interesting
in
that
when
you
bind
a
product
into
an
app
it
gives
you
a
a
key
in
secret
that
you
can
then
use
as
either
your
API
key
access
or
use
to
generate
a
token
and
then
be
able
to
access
through
that.
B
B
Okay,
it
looks
good
okay,
okay,
so
what
you
can
see
here,
I
just
set
up
I'm,
actually
running
on
docker
docker
for
Mac,
and
what
you
see
here
is
just
that
I've
done.
The
install
abyss
do
in
fact
it's
it's.
It's
the
0.8,
rc2
or.
However,
it's
it's
labeled
and
I
have
also
installed
hello.
World
so
should
be
able
to
do
just
a
quick,
see
hello
world
and
you
can
access
both
instances.
B
B
B
And
then
I'll
accept
X
API
key
as
a
request.
Header
other
way.
I'll
also
accept
requests,
API
key
if
you've
installed
the
API
support
and
I
have
a
special
rule
here
that
normally
won't
be
necessary,
but
it's
to
block
out
using
the
header
which
this
security
is
the
OAuth.
The
user
info
header
is
actually
coming
from
the
proxy
for
the
jot
support.
B
Eventually,
it'll
be
an
attribute,
but
right
now
mixer
doesn't
support
that
attribute.
Oops
go
back
here.
The
other
thing
was
what
I
say:
oh
the
handler
itself
very
simple:
basically,
it's
just
the
config
setup
that
you
set
up.
You
know
where
you're
accessing
it,
the
your
organ
environment
and
your
key
and
secret
and
the
key
and
secret
comes
from
when
you
actually
do
your
install
on
Apogee
and
then
finally,
a
rule
which
just
says
if,
if
I'm
not
going
to
ingress,
I
want
to
run
this
rule
everywhere
and
that
can
be
obviously
tweaked
to.
B
B
B
B
C
B
Fantastic
I've
never
seen
that
one,
somehow
the
expiration
or
the
token
availability.
This
is
it
it's
probably
time
stamp
issue,
honestly,
oddly
between
the
server
okay,
let's
assume
for
a
moment
that
this
works,
because
it
does
and
I'll
have
to
look
into
that
earlier.
There
later,
there's,
obviously
some
sort
of
token
issue
there.
B
Here
this
is
the
the
new.
Is
the
authentication
policy
that
you
can
set
up,
and
you
set
up
your
your
information
to
how
to
verify
your
tokens
and
the
targets
and
I'm
saying
it's
a
hello
world
target,
so
I'm
going
to
go
ahead
and
apply
that
now
at
this
point,
what
you'll
see
is
a
different
you'll
get
an
origin
authentication
failed
because
it's
actually
coming
from
the
pilot
or
from
the
proxy
and
you'll
get
it
whether
you
specify
an
API
key
or
not.
B
B
And
now
we
see
we
do
have
access
again,
okay,
API
key
notwithstanding,
and
then
the
only
other
thing
that
you've
noticed
here
is
if
I
keep
trying
this
what's
going
to
happen
is
I'm
going
to
exhaust
my
quota,
I
get
a
429
too
many
requests
and
quota
exceeded,
and
all
that
happened
without
really
without
a
special
configuration
in
ISTE.
Oh,
it
is
all
driven
by
pulling
that
information
down
from
Apogee.
A
Its
I'm
sorry
yeah
I
mean
right
now.
Yeah
I
mean
right
now,
there's
a
little
of
both
right.
The
sto
policy
is
is
defining
high-level
things
that
have
to
happen,
and
one
of
those
high-level
things
that
has
to
happen
is,
you
know,
verify
things
using
Apogee
and
then,
in
this
particular
case,
there's
a
series
of
things
we
can
do.
An
Apogee
I
think
that's
sort
of
an
open
question
going
forward
with
this
to
you,
which
is
at
what
point
does
this
do
configuration
drop-off
and
you
know
let
a
third-party
system
control
things?
D
B
B
You
need
one
one
good
example:
actually
is
a
quota
because
I
I've
opted
now
to
not
implement
the
ischial
quota
as
the
mechanism
for
the
way
Apogee
works,
peppadews
going
to
be
working
as
part
of
the
authentication
and
authorization
by
doing
that,
I
can
completely
control
it
from
the
server
side.
Without
having
to
reconfigure
this
teo
and
its
knowledge
of
our
quotas.
Right.
B
C
C
B
B
The
the
biggest
next
thing
is
going
to
be
that
I'm
going
to
want
to
move
away
from
having
a
specially
compiled
mixer
to
having
a
standalone,
adapter,
yeah
and
I
know
that's
coming
soon,
but
after
that,
I
guess
the
the
biggest
thing
going
forward
from
that
point.
Well
another
thing-
and
you
know
about
this
as
well,
and
that
is
the
inability
to
encrypt
configuration
and
security
yeah.
B
Right
and
then
from
a
feature
aspect
at
some
point,
we're
going
to
want
to
actually
be
able
to
affect
the
requests
right,
so
you
know
whether
it's
changing
adding
removing
headers
or
or
transforming
the
body
we're
going
to
want
some
mechanism
to
be
able
to
do
that.
You
were
in
the
discussion
this
morning
on
the
mix
from
the
mixer
stuff.
C
B
C
C
A
I
mean,
as
we
discussed
a
bunch
of
times,
there's
different
levels
right
fully.
Transforming
the
request
up
in
response
is
one
thing
but
being
able
to
add
or
remove
a
header
is
you
know?
Probably
every
everyone
is
gonna
need
that
you
know
verify
the
OAuth
token,
take
it
off
and
stick
on
a
job.
It's
gonna
be
a
you
know,
super.
C
Common
use
case
right,
okay,
so
given
given
this
audience,
it's
worth
asking
the
question.
So,
in
addition
to
to
editing,
request,
headers
and
perhaps
setting
the
target
the
target
address
for
the
the
final
routing,
what
else
would
be
would
be
useful
for
the
mixer
to
do
in
this
context?
Arbitrary
is:
is
there
other
metadata
that
we
want
to
control
or
because
that's
all
we've
got
so
far.
D
B
A
So
we're
not
using
Apogee
as
a
proxy
we're
using
rack
G,
as
essentially
a
policy
engine
where
we're
doing
you
know
the
guts
of
API
management,
which
is
tell
me
if
this,
if
this
consumer
is
authorized
to
use
the
API
and
by
how
much
other
things
that
get
lumped
under
API
management
like
transforming
requests
and
responses,
are
really
api
gateway,
stuff
and
we've
had
a
bunch
of
meetings
about
that.
But
that's
not
what
we're
trying
to
solve
this
particular
solution.
However,
did
we
get
to
being
able
to
customize
the
error
response
as
well?
A
C
One
thing
that
came
up
this
morning
is
there's
an
open
issue
on
this
and
I
think
it's
just
been
sitting
there
for
a
long
time
and
it's
it's.
My
fault.
I
need
to
go.
Look
at
this,
so
we're
we're
unclear.
It's
not
a
big
discussion.
We
had
this
morning.
It's
it's
unclear.
What
what
errors
mixture
should
so
right
now
adapters
can
produce
errors
fairly.
Complicated
messages
should
mixer
return,
that
to
the
proxy.
Should
the
proxy
return
that
to
the
callers
yeah?
Where
should
that
get
filtered?
It's
it's!
B
There's
there's
a
there's
another
thing
that
doesn't
even
have
to
do
with
with
errors
precisely
and
that
is
with
response,
codes
and
messages
for
like,
for
example,
I
can
return
a
response
code
or
with
with
a
message
from
my
adapter
right
and
I.
Can
I
can
be
as
specific
as
I
want,
but
for
the
authorization
policy,
where
the
judge
token
is
rejected
by
the
proxy
I,
can't
affect
what
that
error
is
intact
like
right
now,
it's
it's
actually
pretty
confusing.
You
only
get
one
error,
it
doesn't
matter.
What's
wrong,
you
will
always
get
a.
B
What
was
that
that
they
showed
you,
it
was
called
I
think
it
just
said:
origin,
yeah
error
or
something
like
that,
and
it
doesn't
tell
you
anything
about
why
it's
wrong.
It
doesn't
tell
you
that
the
job
is
expired
or
that
you
don't
have
one
or
anything
else
is
just
ordinary.
So
that's
probably
something
we
should
address,
but
but
but
I
I
can't
effect
that
from
from
the
policy
at
all,
so
that
that's
what.
B
A
I
mean
generally
people
who
are
exposing
api's
I
found.
They
don't
want
any
kind
of
generic
error
message.
Among
other
things,
the
generic
error
message
tells
you
what
kind
of
software
you
just
got,
the
error
from
which
can
be
very
handy
information.
So,
no
matter
what
generic
error
message
we
come
up
with,
you
know.
Arguably
API
providers
aren't
gonna,
want
it.
They're
gonna
want
to
be
able
to
specify
the
response
code
and
the
message
that
comes
back
for
just
about
anything.
C
A
B
You
can
in
the
adapter,
oh
yeah
yeah.
Your
responses
from
the
adapter
are
passed
back
to
the
client,
but
what's
happening
at
the
proxy
level.
Is
it's
not?
You
have
no
control
over
that
and
then
you
don't
have
control,
whether
it's,
whether
it's
programmatically
or
in
the
configuration
there
is
just
no
control
the.
E
B
So
I
think
there's
there
should
be
two
paths
right.
One
one
path
is:
is
I'm
returning
an
error,
an
actual
error
from
the
adapter
and
that
I
believe,
yes,
that
should
probably
be
filtered
and
not
not
returned,
but
if
I'm
returning
a
response
with
the
code
in
a
message,
I
would
expect
that
message
to
make
it
its
way
to
the
client.
Okay,.
C
C
D
A
D
A
So
you
know
it's
sort
of
it's
a
nice
model
for
the
parts
of
API
management
that
are
these
policy.
Like
things,
you
know
like
verifying,
API,
keys
and
OAuth
tokens,
and
you
know
code
isms
and
things
it's
obviously
you
know
for
the
part
of
API
management.
That's
you
know
turned
my
mainframe
into
an
API.
We
still
need
a
proxy
and
that's
why
we've
had
lots
of
conversations
about.
You
know
how
that
would
plug
into
the
history
of
mesh.
So.
D
A
I
mean
you
know
once
we're
these
do
mixer,
you
know
someone
who
has
10,000
services
running
in
a
giant
mesh
can
simply
say
all
the
ones
that
have
the
attribute
external
API
are
subject
to
the
API
management
policy
and
it's
just
a
very
nice
way
to
sort
of
add
these
kinds
of
policies
to
the
mesh
without
requiring
a
lot
of
configuration
at
the
system
level.
You
know
once
you've
got
the
mixer
and
Appaji
in
there.
You
know
everything
can
be
done.
A
So
you
know
that's
sort
of
what
were,
and
you
know
it's
the
OE.
Still
it's
still
early
days
for
a
CEO,
so
we're
learning
what
customers
really
want
right,
but
you
know
it
seems
to
me
this
whole
micro
services
problem
is
something
that
this
tier
really
does
with
that
hasn't
been
easy
to
dress
book
I
mean.
B
It
should
be
possible
if,
if
we
wanted
to
that,
we
could
write
a
envoy
plugin
and
deliver
that
to
envoy
to
do
our
our
quota
stuff.
But
it's
it's
not
the
the
checks
that
we
do
aren't
aren't
trivial
enough.
I
guess
to
to
be
able
to
do
it
based
on
the
attributes
that
are
and
and
rules
that
are
currently
exposed.
Here
is
BIA
yeah.
A
I
mean
you
know,
keeping
envoy
as
something
that
has
a
fairly
simple
job
to
do
and
can
do
it
very
efficiently
and
reliably
I
think
that's
going
to
be
really
important
to
making
you
steel
meshes
that
are
fast
and
reliable,
doing
stuff
like
jot
verification,
and
you
know,
roll
off
to
JSON
transformation.
I'm,
not
I'm,
not
super
excited
about
doing
that.
A
An
envoy
I
understand
that
it
can
be
done
and
it
hasn't
been
done,
but
you
know
one
could
argue
that
you
know
envoys
should
deal
with
load,
balancing
at
HTTP
and
TLS
and
nothing
else,
and
everything
else
is
potentially
an
unreliable
thing
that
could
break
at
any
moment.
You
have
to
be
prepared
to
have
circuit
breakers
on
it
alright,
but
you
know
the
jury's
out
on
that.
One.
C
Yes,
all
the
stills
extension
model
is
through
mixer
adapters,
primarily
so
that's
kind
of
what
we
want
to
explore
and
what
we're
building
machine
around
for
to
improve.
Caching
allow
offline
operation
for
extended
periods
that
kind
of
stuff.
If
you
call
out
directly
from
the
Envoy,
you
have
to
reinvent
some
of
that
machinery,
like
the
caching
infrastructure,
for
example,.
F
F
Have
a
question:
if
there's
a
free
moment:
yes,
so
one
problem
we're
facing
right
now
from
an
API
management
perspective
is
how
to
control
the
information
that
one
might
proxy
from
an
api
gateway.
So
let's
say
you,
you
send
some
identity
information
that
you
want
to
use
pilot
to
create
a
route
policy,
but
you
ultimately
don't
want
to
send
that
information
to
everybody
right.
Is
there
a
way
to
control
the
propagation
of
information,
or
is
that
a
requirement
that
has
come
up
before
and
it
could
be
done
via
HTTP
header?
F
C
Yeah,
we
don't,
we
don't
currently
have
the
kind
of
facility
with
the
ability
to
do
so.
We
want
to
add
the
ability
for
mixture
to
be
able
to
to
mutate
mutate
headers
as
they
pass
through
the
system.
It
should
be
possible
to
write
an
adapter
that
does
this
kind
of
editing
as
far
as
making
it
stateful
and
I've
keep
for
two
hops
yeah
and
I'm
not
sure
how
to
do
that.
A
A
C
A
Well,
keep
in
mind,
that's
why
it's
important
that
a
mixer
adapter
be
able
to
change
the
HTTP
headers
absolutely
in
Scotts
example.
He
could
verify
the
job.
Take
it
off,
and
you
know,
sir
third
of
all
Espio
off
is
a
very
nice
part
of
the
Museo
mesh
that
gives
you
a
TLS
based
cryptographic,
identity
on
every
service
to
service
integration
and
I.
Think
that's
one
of
the
main
reasons.
People
are.
A
A
Anything
else
so
can
I
ask
in
general
about
this
group
I'm,
sorry,
Martin
and
I.
I
don't
want
to
pre-empting
to
you,
but
we've
struggled
a
little
bit
to
come
up
with.
You
know
entertaining
topics
for
every
two
weeks
and
you
know
Martin's
working
really
hard
on
a
steal.
One
point:
no,
you
know
Scott
and
I
are
working
hard
on
other
stuff.
We
don't
necessarily
have
like
Google,
doesn't
necessarily
have
a
new
spec
to
share
every
two
every
two
or
four
weeks.
A
C
E
Well,
I
can
say
for
myself:
I
have
been
falling
out
all
these
meters
in
the
mixer
meetings.
I
think
there
is
some
convergence
on
that
and
most
of
the
features
we
have
been
discussing
I
think
it
was
the
one
that
was
most
interesting
was
the
mediation
discussion
and
I
think
we
that
talked
but
I
don't
know.
Depending
of
the
agenda
we
have,
maybe
it
could
be
on
demand
approach
because
I
see
we
are
struggling
to
keep
agenda
on
that.
F
E
F
C
Ok,
well,
let's
keep
the
meetings
going
and
we'll
be
a
judge
at
gender
driven.
So
if
you
want
to
throw
topics
on
the
agenda,
we'll
discuss
them
and,
like
I
said,
I
think
after
1.0
ships
in
a
few
months
after
that,
we'll
start
investing
a
real
human
being
human
human
beings
at
writing,
specs
and
adding
functionality.
And
then
this
is
going
to
become
more
interactive
and
an
interesting
role.