►
From YouTube: API Vision working group #9
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
Okay,
this
worked,
I
feel
like
it's
set
up
to
where
it's
only
like
a
lot
of
people
in
once
I've
joined.
I
don't
know
how
this
like
weird
setting
got
set
up
for
like
it's
scheduled
for
1980.
I
don't
know
I
had
so
many
zoom
issues
I'll
have
to
get
to
the
bottom
of
it.
A
A
Okay.
Well,
I'm
going
to
share
my
screen,
we
can
jump
into
the
agenda.
I've
added
a
couple
of
items
there
already.
A
All
right
cool,
so
first
item
is
I've
started
in
on
our
api
vision
and
kind
of
documenting
priorities
based
on
what
we've
learned
so
far,
so
I've
linked
there
to
it.
It
is
in
a
draft
state,
so
absolutely
a
work
in
progress,
hoping
that
if
there
are
questions
about
what
I'm
thinking
so
far
or
something
I'm
missing,
that
we
can
have
some
dialogue
and
keep
iterating
on
that.
A
A
Okay,
next
item
is
this
is
one
topic
in
that
I
kind
of
discuss
in
api
vision
issue
there,
and
I
think
we
haven't
had
a
lot
of
dialogue
on
it
in
this
call.
But
I've
been
trying
to
think
about
how.
How
can
we
avoid
the
manual
effort
in
the
future
of
identifying
where
we
do
have
gaps
when
we're
looking
at
rest
and
graphql
or
when
we're
looking
at
api
coverage?
Overall?
A
How
do
we
know
what
apis
support
each
of
the
features
that
we
have,
so
I'm
wondering
if
there
is
or
should
be
at
least
a
task
defined
for
registering
our
apis.
So
I
don't
know
if
this
would
be
a
process
update,
maybe
an
additional
config
file.
That
was
where
we
store
each
of
the
apis
that
we're
establishing
and
somehow
see
you
have
some
kind
of
point-to-point
connection
between
features,
the
endpoints
and
the
resources
we
have
in
each
of
the
apis.
B
I
think
that's
a
really
great
idea,
especially
if
we
can
automatically
if
we
have
a
configuration
file
or
something
like
that,
that
we
can
automatically
generate
a
a
document
page
for
users
to
be
able
to
see.
Okay
here
are
the
different
features
of
the
different
apis.
So
if
we
can
then
then
produce
something
that
external
consumers
will
read
and
use,
that
will
be
very
helpful.
A
Any
other
thoughts
on
this
and
you
know
broadly,
I
was
just
thinking
you
know-
I
think.
Maybe
this
is
a
little
bit
of
a
solution-oriented
suggestion,
but
just
from
the
problem
statement,
I'm
thinking
how
can
we
avoid
the
manual
effort
of
having
to
do
this
again
in
the
future?
How
can
we
better
understand
the
gaps
that
we
have
and
kind
of
analyze
and
compare
our
apis?
C
Yeah,
I
I
think
like
having
the
configuration
that
we
can
use
for
generating.
That
is
the
nicest
kind
of
solution
we
can
aim.
I'm
thinking
like,
as
as
a
kind
of
boring
solution
like
just
to
get
a
start
with
with
this,
like
with
the
minimal
effort,
wondering
whether
we
could
cross-link
the
end
points
from
the
existing
documentation.
C
We
have
if
it
makes
sense
in
a
way
it's
like
a
it's
still
a
manual
effort,
but
at
least
we
can
flag,
as
this
is
done
somewhere
else
and-
and
we
know,
as
we
add
as
we
maintain
documentation
for
other
api,
we
can
ensure
that
we
actually
add
crosslinks
for
that
and
then
eventually
we
would
have
knocked
out
all
many
ways
to
do
this.
C
But
if
the
effort
of
actually
have
going
through
the
configuration
directly-
it's
not
it's
not
large,
then
we
could
go
directly
with
the
configuration
I'm
just
wondering
like
we
still
need
to
scan
through
all
our
api.
Let's
do
the
kind
of
initial
work
where
we
we
map
the
all
the
things.
B
I
think
into
getting
to
your
question:
is
there
a
way
we
can
avoid
having
to
do
this
manually
in
the
first
place?
I
think
that's
pretty
hard.
We
don't
have
sort
of
a
domain
object
that
represents
a
feature
that
we
can
link
to
or
generate
stuff
from.
So
we
have
to
have
some
kind
of
curation
in
terms
of
defining
here's
the
feature:
here's
where
it's
implemented
in
the
api.
A
That's
like
the
most
official
most
published
location
of
our
features
that
I
understand
that
we
we
kind
of
leverage
that
so
maybe
there's
a
way
to
map
that
and
maybe
create
that
object,
maybe
create
a
place
that
can
become
that
source
of
truth
and
then
build
off
of
that,
and
so
I
don't
know,
maybe
there's
something
that
we
don't
have
there
today,
that
that
we
haven't
needed.
Yet
that
would
really
help
us
address
this
problem
in
the
future.
I.
B
A
And
I
think
that
the
next
question
here-
we've
kind
of
covered-
that
too
can
we
register
aps
somewhere
programmatically
and
capture
the
metadata
so
kind
of
talking
about
a
config
file,
features.aml
etc
fabio.
Do
you
want
to
voice
over
your
question.
C
Yeah,
maybe
to
add
to
the
previous
point:
we
could
probably
have
the
introduce
like
a
concept
of
operation
which
would
be,
for
example,
create
a
pipeline
could
be
the
name
of
the
operation.
Maybe
we
need
to
come
up
with
that.
You
know
a
keyword,
kind
of
a
short
name
for
it
and
and
then
we
could
map
it.
C
You
know
across
the
rest
end
point
or
where,
where
in
the
graphql
mutation
that
would
be,
or
if
it's
in
the
query
will
need
to
map
to
what
type
and
method
or
that
will
map
to
in
a
way
that,
in
terms
of
the
concept
of
operation,
is
kind
of
an
abstraction
okay
that
can
be
implemented
in
rest
or
or
graphql,
and
maybe
kind
of
that
could
be
the
the
common
denominator
across
the
two
different
implementations.
C
On
my
point,
there,
it's
more
like
a
a
question:
how
much
do
we
care
about
the
gaps
in
terms
of
this
operation?
Now,
let's
speak
about
this
operation,
this.
C
Graphql,
it
doesn't
exist
in
rest.
We
have,
for
example,
some
operations
that
we
don't
want
to
have
those
implemented
in
graphql,
for
example,
like
a
runner
to
rails
interaction
through
some
specific
rest
endpoint.
Those
are
all
kind
of
all
interaction
that
will
are
coded
within
the
coroner
code
base
and
use
that
to
interfere
interact
with
rails.
C
For
example,
it
doesn't
make
sense
to
implement
those
in
graphql
unless
we
want
to
convert
the
runner
to
use
graphql
instead,
instead
of
pressed
so
this
kind
of
one-
probably
rather
rare
example,
but
I'm
sure
there's
a
lot
of
other
cases
where
it
might
be
acceptable
to
have
something
in
wrestling
or
not
graphql,
or
vice
versa.
If
something
is
a
very
front-end
feature
specific,
we
don't,
it
might
be,
it's
sufficient
to
just
have
graphql
and
not
rest.
C
I'm
just
wondering,
like
you
know
how
much
do
we
want
to
have
this
feature,
parity
between
rest
and
graphql,
and
and
for
for
me,
they're.
The
main
problem
is
the
differences
in
terms
of
implementation.
That's
probably
the
biggest
problem,
I'm
going
through
the
gap.
Analysis
for
some
of
the
end
points
related
to
verify.
C
I
know
there's
a
lot
of
these
cases
sometimes
are
quite
hidden.
You
know
it
looks
like
it's
using
the
same
service,
but
actually
it's
injecting
different
types
of
params
and
so
and
then
actually
the
implementation
could
be
different
there
and
we
might
have
slightly
different
behaviors.
It's
not
like
a
apparent,
or
sometimes
we
don't
even
use
the
same
service
or
finder.
We
use
just
different
things,
so
those
could
be
even
more
than
your
dangerous
gaps.
C
At
least
we
know
that
if
something
an
operation
is
in
graphql
is
not
in
rest,
we
know
how
to
port
it,
but
when
something
has
been
implemented
and
like
it
actually
differs
from
each
other.
I
think
this
could
be
more
of
a
problem.
B
I
think,
in
terms
of
I
think
you
point
out
there,
one
very
important
category
of
things
we
don't
really
care
about
being
both
that
is
basically
internal
operations,
so
so
that
those
runner
calls
back
to
rails
are
essentially
an
internal
api.
Perhaps
we
want
to
have
an
internal
api
that
is
internal
rest
endpoints,
that
we
don't
expect
external
users
to
use,
and
so
we
can
say
that
internal
operations
can
be
implemented.
B
As
you
see
fit,
I
think
external
ones
where
they
go
where
we
expect
them
to
be
used
by
their
party
clients.
We
have
a
more
a
higher
obligation
to
both
so
there's
the
internal
external
split,
but
there's
also,
I
think,
there's
a
second
category
of
just
technical
limitations.
The
the
prime
candidate
example
of
that
one
is
pipeline,
ci
traces
where
we
we
can't
do
do
not
want
to
stream
ci
traces
now
through
graphql,
because
it's
just
never
going
to
be
efficient.
B
So
we
want
to
leave
that
and
rest
entirely
and
anything
that
pulls
stuff
out
of
the
object
store
as
well.
C
Yeah
well,
another
example
would
be
like
suddenly
from
the
front
end
we'll
need
to
add
to
an
existing
type
another
attribute,
and
so
what
do
we
do?
If
we
add
a
new
attribute
to
an
existing
graphical
type,
do
we
need
to
add
also
to
the
rest?
The
problem
is
that
our
rest
payload
and
it
keeps
growing,
and
it
brings
back
the
same
problem
where
we
have
today
with
a
lot
of
the
the
scenarios,
especially.
B
I'm
coming
to
think
that
it
actually
makes
a
lot
of
sense
to
have
the
the
rest.
Payload
be
essentially
a
core
version
of
a
core
representation
of
an
object,
and
if
you
want
more
stuff,
it's
there
go
to
graphql,
you
can
get
it,
you
want
it.
You
can
get
whatever
you
want
and
so
yeah,
that's
the
rest
of
zomakaze
graph,
girls
that
bella
can't
and
it's
okay
to
offer
both,
and
so
it's,
I
think,
there's
right.
C
C
Do
I
need
to
use
like
a
mix
of
rest
and
graphql,
or
you
know
if
I
want
to
get
extra
stuff
they're
not
supported
by
restore,
do
we
need
to
have
a
way
for
rest
to
be
extensible
like
graphql,
where
you
say
I
want
to
include
these
extra
objects.
You
know
maybe
not
like
field
by
field,
but
let's
say
in
my
pipeline
payload
I
want
to
include
the
the
user
and
I
also
wanted
to
do
the
jobs
with
it.
C
But
by
default
you
only
get
like
a
minimalistic
pipeline
payload,
for
example,
kind
of
macro
objects,
yeah.
B
This
is,
this
is
very
similar
to
the
json
api
yeah
yeah,
and
I
think
I
think,
that's
yeah.
That's
a
good
place
to
move
based
towards
if
we
do
an
api
5.
C
A
Yeah,
then,
maybe
that
that's
something
that
we
could
this
question,
we
could
document
a
little
bit
better
and
I
can
dig
into
more.
I
think
that
the
conversations
I
have.
A
B
If
you're
requesting
issues,
should
you
and
you
can
you-
you
could
just
be
issued
that
data
by
default,
but
could
you
should
you
then
be
able
to
say
our
issues
by
the
way
with
every
issue?
You
also
told
me
everything
about
this
also
also
give
me
the
requests
that
are
associated
with
it
and
so
forth.
These
extra
associations.
A
Okay,
that
makes
more
sense
now.
I
I
think,
with
a
couple
of
cases
that
I
have
heard
that
are
more
explicit,
like
more
like
defined
in
a
little
bit
more
detail.
That
is
something
that
customers
are
asking
for.
A
I
think
the
big
one
is
they're
trying
to
traverse
across
like
groups
projects,
users,
and
then
they
just
want
certain
types
of
information
and,
of
course
it
seems
like
in
some
cases
graphql
could
be
a
good
fit
for
that,
but
yeah
they've
been
generally
using
rest,
and
so
there
could
be
large
scale
changes
required
to
go
completely
from
rest
to
graphql.
A
So
I
think
to
fabio
your
original
question
and
I
think
a
lot
of
this
I'm
trying
to
communicate
in
that
in
that
issue
I
just
shared-
and
hopefully
I'll,
take
that
to
mr,
but
is
that
we,
I
think
first
want
to
close
the
gaps
in
graphql
and
try
to
provide
some
confidence
for
our
customers
that
when
we
do
build
new
features
that
they
get
into
the
graphql
api
every
case
that
is
possible
and-
and
I
agree
with
alex's
point
that
we're
focusing
here
on
the
externally
facing
endpoints.
A
B
That
does
actually
require
that
we
have
that
we're
aware
of
their
total
accidental
find
if
we
don't
stick
stuff
in
our
external
wrist
schema.
If
we,
if
it's
actually
just
an
internal
api.
A
B
B
Is
that
it's
essentially
an
external
api,
if
there's
stuff
under
there
that
actually
isn't
it
really
is
only
for
internal
use?
Well,
maybe
we
need
to
be
a
bit
clear
about
this.
B
I'm
not
sure
what
particularly
which
ones
you're
referring
to
fabio,
whether
these
are
under
api,
v4
or
somewhere
else,
but
yeah.
C
The
one
really
to
the
runner,
and
so
there
is
like
a
registering
runner,
requesting
jobs
from
a
runner,
so
those
are
actually
coated
with
our
together
with
our
external
endpoints,
which
is
what
are
used
by
the
runner.
A
Yeah,
so
to
conclude
that
the
original
question
is
it
acceptable
to
have
gaps?
I
think
that,
first
and
foremost,
where
possible,
solving
them
in
in
graphql,
where
we
have
gaps
and
then
keeping
in
mind
that
a
large
amount
of
our
users
or
perspective
users
are
still
dependent
on
rest,
familiar
with
rest
rest,
reticent
to
move
to
graphql,
don't
fully
see
the
value,
so
I
think
it's
going
to
be
a
gradual
process
to
educate
them,
show
them
the
use
cases
where
it
makes
sense.
A
So
I
think
as
much
as
possible,
then
once
it's
in
graphql
that
we
automate
or
make
it
as
simple
as
possible
to
come
back
like
come
backwards
and,
like
start
adding
these
rest.
These
rest
endpoints
that
wrap
the
resources
and
graphql
that
that
we're
kind
of
pocking-
and
I
get
your
point
fabio
where
there
are
inconsistencies
like
I
don't
know
quite
how
we
could
address
those
or
how
to
fit
those
in
the
prioritization.
A
But
I
do
think
that
makes
sense
like
that
could
be
more
dangerous
because
we,
the
behaviors,
could
be
different
to
our
customers
and
and
use
our
users
in
general
and
yeah.
A
Right
as
we
gradually
move
towards
that,
so
that
that
is
kind
of,
I
think
what
I
could
see
us
doing.
Of
course,
assuming
that
we've
addressed
some
of
the
risks
like
is
performance,
how
how
much
will
performance
be
impacted
if
we
approach
it
this
way,
but
that's
something
I
think
in
the
implementation
details
to
sort
out
yeah.
I
think
if
you're
a
customer
you're
used
to
rest,
you
jump
right
into
rest
and
then,
as
you
get
deeper
and
you
start
to
see
well,
performance
is
important.
A
B
One
of
the
things
that
I
realized,
that
was
quite
nice
about
wrapping
rest
around
graphql,
is
that
it
provides
that
first
episode.
One
thing
you
that
each
rest
point
can
then
do
is
you?
Can
you
can
tell
me?
How
are
you
augmented
give
me
the
graphql
query
that
does
what
you
do
and
then
you
can
just
spit
out
the
graphical
query,
so
that
becomes
a
way
of
of
educating
the
user
once
once
they
use
that
that
you're
that
endpoint
and
they
go.
I
want
to
do
this.
B
A
That
is
really
cool.
Actually,
I
feel
like
that's
how
I
could
learn
how
to
use
graphql
a
little
bit
better
coming
from
more
of
a
rest
background,
a
good
point.
C
So
so,
to
summarize
that,
like
we,
I'm
assuming
we,
you
know,
we
we're
gonna,
dig
in
more
with
the
good
wrapping
graphical
with
rest
interface.
We
want
to
do
the
graphql
first
and
then
rest
when
needed
when
needed.
Some
customers
need
to
have
the
that
that
being
implemented,
the
rest
of
the
case,
we
will
convert
the
graphql
into
a
rest
just
by
adding
a
new
endpoint
and
wrap
that
so
the
graphql
will
be
primarily
kind
of
the
superset,
except
some
special
cases
will
be
a
superset
of
rest,
yeah.
A
I
think
that
is
the
objective
and
how
it's,
how
I've
kind
of
put
it
into
that
prioritization
issue.
I
just
mentioned
again
draft
state,
so
I
think
that
you
know,
after
this
call
or
this
week,
taking
a
look
through
that
and
see
if
it's,
if
everything's
kind
of
lining
up,
I
think
there's
some
things
we're
talking
about
now
that
aren't
captured
there,
so
we
can
and
maybe
they're
they're
more
nuanced
details
that
don't
need
to
be
in
this
particular
section
but
yeah.
A
I
think
it
lays
it
out
just
as
we've
discussed
and
we
can
have
some
more
discussions
from
there
if
I'm
missing
something.
A
Cool
all
right,
I'll
move
on
to
the
next
item.
I
think
we've
used
most
of
our
time
so
I'll
try
to
keep
it
high
level
gap
analysis.
I
just
wanted
to
follow
up
and
see.
You
know
if
there
are
any
challenges
there,
how
the
progress
is
going.
I
added
suggested,
I
guess
a
target
date.
To
conclude,
this
is
a
kind
of
a
beta
evaluation
of
the
gap
analysis
so
june
27th.
A
Is
that
target,
but
my
hope
is,
after
this
initial
kind
of
pass-through
that
we
come
together
and
say:
can
we
make
this
a
little
bit
easier
for
the
rest
of
gitlab
to
to
to
follow
and
to
go
through,
and
are
we
getting
the
value
out
of
it
that
we
hoped
and
one
of
the
one
of
the
pieces
of
it
I've
seen
like
everyone
is
pretty
well,
I
think
able
to
go
in
and
discover
their
apis
and
then
start
to
identify
the
gaps
which
is
great
and
thanks
fabio
for
for
for
sharing
this
across
some
of
the
other
channels.
A
That's
been
really
helpful,
but
one
thing
I
haven't
seen
as
much
as
what
we're
getting
into
estimating
like
what
is
the
effort
required,
and
maybe
this
isn't
the
place
to
do
it.
Maybe
we
just
separate
the
two
out
and
say:
let's
just
capture
the
gaps
and
then
another
take
another
approach
to
how
we
kind
of
estimate.
What
is
the
scope
of
this?
This
whole
thing
like
we
want
to
address
gaps?
A
How
much
effort
is
it
going
to
take
so
a
couple
of
ideas
ahead
on
that
is
we
could
sample
so
each
of
our
groups?
Let's
pick
a
couple
of
issues
there,
a
couple
of
gaps
and
estimate
and
kind
of
classify,
because
there's
a
different
scope
for
building
an
entirely
new
api,
a
new
feature
versus
you
know,
changing
some
parameters
or
whatever
the
case
might
be,
and
then
we
kind
of
start
to
to
do
that
across
the
teams.
I
think
that
could
be
one
approach.
A
Another
could
be
surveying
each
of
the
teams
to
say
here's,
some
classific,
like
classes
or
categories
of
effort.
What
do
we
anticipate?
What
what
have
we
seen
in
our
experience
and
as
an
example
of
what
that
could
look
like
I've,
seen
these
postman
results,
which
I
shared
in
the
slides
as
well,
for
the
api
users
survey
information
and
they
what
they
heard
from
customers
using
postman?
A
Is
that
a
third
of
their
respondents?
I
felt
like
it
usually
takes
one
day
to
one
week
to
get
an
api
into
production,
and
then
another
third
felt
that
it
took
them
one
week
to
one
month
so
somewhere
between
a
day
and
a
month.
But
you
know
how
can
we
break
that
down
into
something
that
can
help
us
to
scope
and
estimate
so
went
through
a
lot
of
that
very
quickly,
but
any
immediate
thoughts
on
that.
A
Cool
and
I'll
just
run
through,
but
if
you
have
any
other
thoughts,
anyone
on
the
call
just
please
add
them
here.
I
don't
want
to
take
up
too
much
more
time.
Graphql
rest
over
graphql,
I'm
calling
it
rest
over
graphql,
please
suggest
a
better
to
soundspring,
but
yeah.
If
we
well,
I
guess:
where
do
we
want
to
go
next
with
this
poc
there's
the
issue?
I.
B
I
I
have
a
acute
sort
of
codename
for
internally
out
there,
calling
it
raisin,
because
dehydrated
grape.
B
Yeah
so
how's
it
going
basically
hasn't,
haven't
really
touched
over
the
last
couple
weeks,
so
got
to
a
working
state
and
I've
been
working
on
actual
real
things.
Well,
the
question
is
like
what
are
what's
up
prioritization,
if
you
want
more
work
done
on
this
I'll
check
with
my
engineering
manager
and,
of
course,
you
and
see
where
how
much
busy,
how
quickly
you
actually
like
this
move
forward,
so
we
can
actually
start
using
it
in
a
real
way.
A
A
Okay,
cool,
so
that's
what
I
was
thinking
of
as
the
next
step.
That's
what
I
propose
is
that
anyone
on
this
call
anyone
watching
after
the
fact
if
your
teams
want
to
participate,
if
we
know
that
we're
missing
you
we're
going
through
this
gap
analysis
right
now,
we
can
see
hey,
there's
some
apis
that
are
missing
and
rest.
A
We
have
the
graphql
endpoint.
Can
we
just
try
this
out,
see
and
see
what
the
team
thinks
see
if
you
see
any
deficiencies,
any
challenges
or
risks,
so
that
I
think,
would
be
a
really
great
next
step
and
trying
to
work
it
in
just.
I
know
we
all
have
lots
of
other
priorities,
so
more
so
just
internally
dog
fooding
a
little
bit
and
then
we
can
kind
of
define
next
steps
further
from
there.
A
So
come
to
the
notes
and
share
your
name
to
volunteer
here.
Okay-
and
I
know
we're
at
time
so
probably
not
gonna-
be
able
to
get
into
deep
discussion
on
this
one.
So
I'll
just
touch
on
it.
We
can
have
discussion
and
issues,
but
in
the
api
vision,
privatization
issue,
I'm
thinking
I'm
wondering
if
we
should
keep
an
api
version,
5
a
new
version
of
our
api
out
of
scope.
A
Initially,
it
seems
like
we
have
quite
a
bit
of
work
that
we
can
accomplish
before
introducing
some
major
breaking
changes
and
I'm
not
getting
the
sense
that
we're
identifying
what
necessitates
that
change
very
quickly
right
now,
but
I
could
be
wrong
on
that.
So
my
my
thought
is:
if
we
keep
it
out
of
scope,
we
start
some
issue
or
have
some
really
defined
process
to
start
to
flesh
these
out
document
them
over
time.
A
Work
on
a
lot
of
these
other
problem
statements
like
automating
the
documentation
addressing
the
gaps
that
we
can
in
the
current
version
or
versions
or
api,
and
I'm
also
understanding
like
graphql
in
a
lot
of
ways,
is
version
lists.
So
how
does
that
play
a
part?
I
think
these
are
things
that
we
can
understand
a
little
bit
better
before
we
start
making
some
major
sweeping
changes.
This
is
just
my
intuition,
though,
and
I'd
like
to
get
more
feedback.