►
From YouTube: Request/reply discussion
Description
Meeting that covers topic of request and reply in AsyncAPI spec. Related GitHub issue: https://github.com/asyncapi/spec/issues/94
A
Before
we're
gonna
understand
and
and
for
others
why
we're
live
streaming,
it's
like,
because,
whatever
we
do
at
awesome
api,
it's
yeah,
it
should
always
be
available
to
everyone.
So
it's
for
us
live
stream
is
much
easier
way
to
make
sure
that
the
recording
stays
there
after
the
after
the
meeting.
A
You
were
sharing
sharon,
galen
gonzo,
okay,
so
you
can
continue
and
I
will
share
a
link
on
slack.
I
mean
link
to
the
livestream.
B
C
Yeah,
hello
yeah,
my
name
is
heiko,
I'm
working
for
a
bigger
swiss
company
and
I'm
responsible
for
company
internal
messaging,
so
many
are
managing
up
to
100
micro
services
using
messaging
and
now
we
are
have
to
support
the
request
supply
pattern.
So
I
want
to
drive
that
topic
a
little
bit
forward.
B
Great
yeah,
so
I
guess
we
can
just
get
right
into
it.
Do
you
want
to
share.
C
So,
first
let
me
go
through
the
use
cases
I
collected
with
some
colleagues
here
we
see
four
different
use.
Cases
for
request
apply.
First,
three
are
topic-based
so
using
a
standard
message
broker.
C
Here
I
see
the
first
use
case.
I
have
a
well-defined
response,
topic
and
correlation
id,
so
the
response
topic
is
defined
in
the
schema.
It's
not
part
of
the
request
message.
Only
the
correlation
id
is
part
of
the
request
message
saying
hey:
this
is
the
id
I
requested
so
and
if
I
get
a
response,
the
response
also
contains
the
correlation
id.
So
the
requester
knows
hey,
that's
the
response
to
my
request.
C
C
So
this
is
a
topic
name
with
random
number,
cutting
or
whatever
that
only
my
process
is
using
so
only
my
process
getting
the
response,
not
everyone
and
again
in
correlation
id.
So
I,
if
I
do
parallel
request,
I
need
to
know
what
is
the
response
to
my
request.
C
C
C
E
C
E
Just
before
you
continue
like
publish
and
subscribe,
you
can
get
rid
of
publish
and
subscribe
in
version
three
okay,
so
this
is
gonna.
I
I
see
that
you
have
a
question
there.
So
just
before
people,
okay,.
C
F
C
Okay,
so
message
flow
direction
is
now
handled
by
operations.
C
C
E
So
this
this
was
just
a
suggestion,
but
yeah
one
of
the
suggestions
is
that
that
you
can
overwrite
this
so
for
a
specific
operation,
you
can
overwrite
the
default
of
the
channel,
so
you
can
standardize
what's
happening
on
the
channel
like
a
channel
level.
You
have
this
message
yeah,
but
a
specific
operation
can
override
it.
One
suggestion
I
mean
it
is:
it
can
make
the
the
specification
a
little
bit
complicated.
E
So
one
suggestion
that
was
mentioned
once
is
that
we
somehow
give
names
to
the
messages,
so
the
the
channel
will
contain
a
list
of
allowed
messages.
Each.
E
E
That
are
allowed
like
not
all
of
them,
but
just
this
one
or
just
these
two,
you
know
what
I
mean.
E
Because
so
the
thing
the
thing
about
having
a
default
on
the
channel
is
the
cool
thing
about
having
it
in
the
channel.
Is
that
it's
easier
for
companies
to
standardize
on
specific
message
per
topic
or
set
of
messages
per
topic?
So
then
it's
easier
to
understand,
what's
being
published
into
this
topic
or
channel
right.
But
if
you
allow
people
to
override
these
and
operations
only
without
standardizing
them
channel,
then
it's
much
more
powerful.
F
C
E
But
the
reality
is
that
people
are
sometimes
publishing
multiple
messages
yeah
and
what
you
do
usually
in
type
messages
is
that
you
try.
You
try
catch
parsing,
one
type
of
message
and
if
it
fails,
you
try
with
a
different
one
and
then
a
different
one
until
something
parses
and
if
none
of
them
parse
it
then
yeah.
E
And
then
you
can
some
linting,
for
instance,
linters,
like
as
I
call
this
one
from
can't
remember
anyway,
so
linters
can
help
you
with
this,
so
companies
can
set
up
linkedin
rules
like
you
cannot
have
one
more
than
more
than
one
message
per
channel
and
it's
not
allowing
our
company
or
something
like
that.
That's.
E
E
F
C
C
E
Yeah,
I
think
we
can
make
anything
possible
like
we're
still
defining
this,
so
that's
like
everything's
a
bit
possible,
but
what
I
my
my
opinion
here
is
that
you
can
have
like
a
set
of
allowed
messages
that
you
might
use
to
reply
to
be
cool
to
understand
like
where
am
I
getting
the
topic
from
you
know
what
I
mean.
E
So
the
topic
in
this
case
is
dynamic,
like
it's
in
a
header
or
something
like
that,
or
in
or
in
or
a
property
of
the
body
tells
you
where
to
reply
or
something
like
that.
It
will
be
cool
to
know
that
to
or
to
be
able
to
point
to
that,
like
you
have
to
so
that
the
information
of
where
to
reply
is
on
the
header
reply
to
of
the
original.
F
E
Or
it's
on
the
body
on
the
property,
blah
blah
blah,
whatever
right.
C
C
Whatever
yeah,
we
can
come
up
with
a
x
epsilon
set.
C
C
Case
channel
and
what
years
like,
I
subscribed
to.
F
C
This
channel,
where
it
is.
E
It
can
can't
it
be
like
just
an
idea
like
can't
it
be
like
channel
is
assumed
to
be
the
same
as
the
the
one
above
the
one
of
the
requests.
Since
it's
a
reply,
the
channel
is,
is
the
same
as
the
like.
Where
do
you
grab
the
the
I'm
not
saying
that
we
reply
to
the
same
channel?
I'm
saying
that
we
read
from
the
message
on
on
the
request.
E
We
read
the
header
and
there's
a
reply
to
header
there.
We
get
this
topic
and
that
will
be
the
topic
where
we
will
reply.
So
you
don't
need
to
specify
the
channel
again
right.
C
C
C
My
a
point-
my
point
was
just
using
a
channel
for
that
here.
I
have
a
topic
I
can
have
in
white
cards
within
here
and
define
messages
whatever
and
just
say:
hey
my
replay
to
source
is
source
general.
F
C
E
Is
it?
Is
it
not
the
same
example
as
is
isn't
that
the
same
as
I
don't
know,
it's
not
the
same,
as
example,
a
no.
E
C
Have
to
match
a
pattern:
you
have
to
go
using
this
broker
and
things
like
that.
E
So
the
in
this
case
I
will,
I
will
suggest
using
regex
like
you-
can
provide
the
rejects
for
the
channel.
E
It's
in
the
format
of
the
underlying
technology
that
you're
using,
for
instance,
kafka,
doesn't
allow
these
slashes
right,
but
you
might
want
to
transform
this
classes
with
underscores,
or
something
like
that.
So
so
I
will,
I
will
just
say
like
this-
should
be
matching
against
this
rejects
like
reply,
two
headers
will
be
matching
against
this
regex
and.
C
It
can
be
mean
something
like
source.
C
Let's
say,
don't
want
to
have
the
channel
here
and
validation
or
pattern.
C
Then
you
could
say:
hey
my
response.
Channel.
E
E
So
we
cannot
point
to
a
channel
definition
because
then,
or
or
the
chat
or
the
or
the
system
that
we
have
the
the
channel
format
the
channel
syntax,
because
it
might,
it
may
not
match
right
and
and
also
I
think,
regex
will
be
more
like
generic
and
then
and
and
easy
to
understand
for
people.
I
don't
know
what
what
other
others
think
here,
but
yeah
just.
F
E
There's
usually,
there
there's
usually
a
a
reason
like,
for
instance,
with
with
rpc
some
people.
What
they
do
is
that
they
distribute
the
replies
in
different
queues
for
visual
queues
for
different
consumers.
So
so
that
will
be
a
reason.
C
Yeah,
but
what
I
mention
more
is
where's.
The
channel
object,
general
object.
What
is
a
part
of
a
general
description,
subscription,
publish
we
ignore
parameters
and
bindings
yeah,
but
then
you
think
I
guess.
Parameters
and
binding
should
always
be
the
same
for
request
and
reply,
or
is
there
any
reason
to
have
different
parameters
and
bindings
for
on
reply,
then?
Do
you
have
on
a
request.
E
Thing
is
that
I
think
we're
trying
to
do
two
different
things,
so
I
was
trying
to
just
understand
where
you're
sending
the
reply
yeah
and
that's
it
I'm
stopping
there,
and
I
think
you
want
to
define
the
the
full
channel
like.
Where
are
you
going
to
send
the
reply
to
right
when
the
reply
channel
is
known?
E
Even
if
it's
just
a
pattern,
but
it's
known
and
you
know
more
or
less,
the
structure
is
going
to
have,
then
it
works.
But,
for
instance,
the
other
day.
I
think,
two
weeks
ago
I
had
to
chat
with
a
fault
from
from
sap
on
thinking
out
loud,
and
he
was
mentioning
that
the
reply.
E
The
message
could
be
sent
to
any
topic
because
and
any
topic
like
like
any
because
the
user,
the
customer
is
able
to
configure
through
an
interface
to
create
a
new
topic
and
to
and
to
put
the
name
of
the
topic
there.
So
in
this
case
it
doesn't
even
have
to
follow
a
pattern
right.
So
so,
in
this
case,.
C
Right
only
asking
is
there
a
need
for
that
in
some,
so
there's
some
use
case
to
you
need
to
define
in
general
at
the
moment
I
don't
think
there
is
any
need
for
no.
I.
E
E
C
So
yeah
sure,
but
I
have
to
support
this
10
up
to
100
mqtt
applications.
So
I
don't.
E
G
Interested
in
how
we
describe
where
the
reply
is
going
to,
because
I
don't
think
it's
a
given,
that
it's
necessarily
going
to
be
the
same
server
as
that's
where
the
request
is.
Is
that
supported
by
what
you've
described?
And
it
might
be
that
it
is.
I
just
haven't,
really
thought
through
the
implications.
No.
C
C
A
You're
looking
at
2-0
version,
but
two
three,
we
added
a
a
way
to
link
channel
to
a
specific
server.
A
E
So
I
think
I
think,
as
look,
I
think
it
will
be
cool
like
whenever
it's
possible-
let's
let
the
user
point
to
another
channel
right
like
this
is
going
to
the
reply
is
going
to
be
sent
to
another
channel,
but
in
some
cases
like
we
don't
we
cannot
define
the
channel
upfront
in
the
next
api
file
because
it's
so
dynamic
that
we
don't
know
right.
So
in
this
case,
this
will
also
give
the
option
to
to
just
have
it
string
like
reply
to
here
to
this
name
of
the
topic.
E
We
don't
know
what
it
is,
or
it's
not
defined
anywhere,
and
it's
not
defined
anywhere
in
this
api
channel.
In
this
api
document.
F
B
For
example,
for
nets,
it
doesn't
care
what
the
reply
channel
is
it's
built
in.
So
it's
basically
just
a
http
http
request
similar
action,
so
you
just
send
the
request
and
you
get
a
reply
on
yeah.
I
think
they
had
internally.
They
add
something
like
a
reply:
dot
and
then
the
channel,
but
it's
not
something
that
you
conceptually
have
to
do
anything
about.
C
A
Can
you
scroll
a
bit
up,
can
you
yeah,
thank
you.
F
B
F
B
E
C
This
is
for
me
as
a
request
law.
This
is
more
I
receive.
I
don't
know
what
actions
you
have
planned
here
here
I
receive
it
and
then
it's
more
the
same.
Oh
I
just
in
this
case
I
send
the
create
user,
and
here
I
receive
the
create
user
and
the
rare
define
is
the
same.
I
just
have
to
find
a
reply.
How
I
would
so
only.
E
Yeah,
I
think
the
opposite
side
will
be
just
they
receive,
of
course
there,
but
yeah
it
would
be
cool
yeah.
E
Yeah
yeah,
but
I
mean,
if
the,
if
the
it's
the
same,
but
imagine
that
you're
the
user,
this
opposite
that
you
had
you're
highlighting
there
and
you
only
have
this
information,
you,
don't
you
don't
have
the
other
information
above
you
you
don't
know.
This
is
a
request
right.
You
don't
know.
This
is
a.
C
D
B
F
C
C
E
So
so
what?
If?
What?
If
the
message
there
is
a
property
in
the
message
that
it
says
this
message
is
a
request
so
not
on
the
not
on
the
not
on
the
operation.
The
operation
will
still
be
send
and
receive,
but
so
there
is
no
request,
operation
or
yeah,
there's
no
request
operation
and
on
the
message
at
message
level.
E
We
say
like
this
message:
this
message
is
a
request:
it's
a
request
with
headers
and
body
right
with
headers
and
payload,
and
then
depending
if
you
send
in
the
message,
then
you
send
in
the
request,
if
you're
receiving
the
message,
you're
receiving
a
request,
you're
you're
a
server
if
you're
receiving
a
request,
it's
because
you're
a
server
right.
So
then,
in
this
case
it's
your
server
or
you
are
a
server
in
the
case
of
rpc
over
over
broker.
E
E
C
E
Right
now
we
are
defining
an
issue
kpi
for
each
of
them.
That's
the
way
it
is
so.
The
client
has
a
send
method,
I
send
operations
or
it
has
a
send
operation
and
it's
sending
a
message
to
the
server
and
the
server
is
receiving.
E
C
The
recruit
the
required
headers
should
be
part
of
the
message.
Yeah,
I'm
with
you,
the
reply
to
header
and
the
correlation
id
should
be
part
of
the
message.
Definition.
B
E
No,
we
can
have
that
on
the
on
the
on
the
operation,
so
the
operation
can
have
like
send
this
message:
send
this
reply
right
to
this
specific
channel
or
to
this
so
but
the
the
metadata
that
that
makes
you
understand
that
this
message
is
a
request
or
is
a
response.
This
metadata
is
in
the
message:
it's
not
on
the
it's
not
on
the
operation.
You
know
what
I
mean
so
imagine
that
we
we
have
there
one
more
field
and
it's
type
request,
type
response.
C
Yeah
normally
is
that,
like
this
type,
payload
nowadays,
just
give
me
a
second
type
object
where
the
properties-
this
is
the
keyword.
I
want
to
more
type
object
properties,
reply
to.
E
E
A
request:
this
is
a
request
right,
it's
true,
it
says
in
the
on
the
on
the
on
the
summary:
it
represents
an
explicit
request.
E
Oh
well,
yeah
yeah,
you're,
right,
you're
right,
so,
okay,
so
let's
leave
it
there.
Let's
now.
One
thing
that
comes
to
mind
is:
if
I
read
this
message
alone,
I
don't
know
this
is
a
request.
E
I
mean
as
a
user
as
a
human
yeah,
but
as
a
machine
I
don't
know,
this
is
a
request
or
if
this
is
a
plain,
normal
message
and
a
broker
right.
So
when.
E
Will
it
will
it
be
like
just
put
there
that
this
message
is
a
request
somewhere,
like
you
have
at
the
same
level
as
headers
and
payload?
You
have
something
like
I
don't
know
kind
request,
something
like
that.
C
F
E
C
If
one
use
create
user
synchronized,
you
have
those
reply
to
and
in
other
unconcious
way
is
just
fire
and
forget,
but
just
let's
call
it
fair
now
to
make
it
more
clear.
E
In
this
case,
but
when
you
have
a
message,
a
message
is
always:
if,
if
a
message
is
a
request,
I
truly
cannot
think
of
a
case.
Maybe
if
I
think
about
it
a
little
bit
more.
I
come
up
with
the
case
but
like
if
a
message
is
a
request,
I
don't
think
it
can
be
used
or
it's.
It
will
be
used
as
a
non-request,
like
I
don't
know
like
and
also
I
don't
think
it's
all,
because
we
have
properties
at
the
message
level,
like
the
summary
saying,
represents
an
explicit
request.
E
C
C
I
still
need
to
define
the
I
have
to.
I
have
to
find
the
header
I
have
so
I
might
get
rid
of
this
one,
but.
E
E
Yeah,
you
need
to
specify
what
is
the
reply
to
a
header
like
where
you
will
so
we
find
this
information.
You
still
need
that.
That's
fine,
that's
completely
fine!
I
was
I
was
saying
this
because
we
were
discussing
like
how
would
it
look
like
from
the
client
point
of
view
right
like
this
opposite
example
that
you
created
this
could
be
solved
by
moving
this
to
the
message
so
saying
that
a
message
is
a
request.
E
We
can
even
then
explore
further
in
the
future
like
there
are
different
kinds
of
messages.
There
are
requests,
requests
responses,
of
course,
but
there
are
in
in
normal,
let's
say
in
in
the
usual
broker
brokers,
let's
say
yeah
the
usual
broker
architectures.
E
You
have
this
change
data
capture
type
of
message,
so
you
can
then
specify.
So
this
is
a
message
that
is,
it's
also
called
fat
messages
or
rest
messages,
so
so,
for
instance,
there
is,
there
is
a
kind
of
messages
of
message
that
is.
Whenever
I
update
a
record
on
the
database,
I
want
to
publish
a
message
to
the
to
the
broker
just.
E
Not
just
like
sending
all
the
info
all
the
new
object,
like
imagine,
I
create
a
new,
I
create
a
new
user,
I
create
a
user
in
the
database
and
once
I
have
all
the
information,
I
publish
a
message
to
the
broker
with
all
the
information
about
the
new
user.
E
Everything
like
the
id,
the
name,
the
email,
everything
everything
goes
there,
that's
one
kind
of
message,
but
there's
another
one
kind
of
message
and
another
way
of
doing
this,
which
is
you
don't
publish
all
the
information
to
the
broker,
but
just
establish
a
message
with
a
single
property
which
is
the
id
of
the
of
the
user.
And
if
you
need
to
get
the
information
of
the
user,
then
the
client
will
call
the
api
to
retrieve
everything
from
the
database
right,
so
that
these
types
of
messages
are
useful.
E
Sometimes
one
is
called
fat
messages
because
it
has
lots
of
information
and
the
other
one
is
is
like
it
has
less
right.
So
so
yeah,
I
think
it's
event
notification,
if
I'm
not
mistaken
in
the
second
one.
So
if
we
have
this
type
of
this
kind
of
property
on
the
message
can
be
a
response
can
be
a
request.
It
can
be
a
change.
Data
capture
can
be
a
event
notification.
There
are
many
types
of
messages
that
we
might
want
to
add
in
the
future,
so
so
yeah.
C
C
So,
let's
get
back
here
to
the
use
cases.
You
have
one
use
case
where
you
only
have
a
well-defined
response
topic.
It's
not
part
of
the
message.
You
will
always
need
the
operation
to
know
where
to
response
to
in
this
case
here
so
on
the
server
side,
you
will
need
an
operation,
you
cannot
do
it
without.
E
C
E
We
have
send
and
receive
yeah,
it's
just
that
we
don't
have
special
actions
or
anything
just
send
and
receive,
and
now
to
know
that
what
you're
sending
is
a
request.
E
You
need
to
check
if
the
message
has
the
type
request
right,
you
know
what
I
mean
and
also
the
receiver
will
be
the
server
right.
We
need
to
check
if
the
the
message
has
kind
of
request
and
therefore,
for
instance,
if
I'm
generating
code,
I
will
generate
the
server.
I
will
not
generate
a
a
let's
say:
a
broker
client
or
I
generate
a
broker
client,
but
I
expect
to
generate
a
different
code
because
I
know
it's
a
request,
so
I
will
at
some
point
have
to
reply.
You
know
what
I
mean.
E
We
just
need
to
hint
that
the
message
is
of
of
type
request
or
response
or
whatever
then
reply
here
can
be
on
in
the
in
the
first
case,
in
the
in
the
a
example
that
you
have
above,
where
the
channel
is
specific
channel
always
the
same,
then
we
can
just
say
like
it's
channel
whatever.
This
is
the
name
of
the
channel
that
you,
where
you
have
to
specify
where
you
have
to
send
it.
E
We
can
have
the
other
options
which
is
reply,
topic
or
reply
channel
or
I
don't
know
how
to
call
it
like
or
reply
to
right
and
then
the
source
is
either
a
header
or
a
body
and
and
and
that's
fine
and
I
think
yeah.
We
need
a
message
you're
right,
so
we
still
need
a
message.
There
yeah,
I
think
so.
E
E
E
E
So
let's
say
just
generic,
we
don't
know,
and
then
it's
like
generic
request
or
response.
In
this
case
it
will
be
a
request
in
the
case
of
the
of
the
creation
failed
or
user
created.
It
will
be.
E
So
we
have
a
message
in
the
chat
in
json
rpc
when
a
notification
is
sent
by
the
client.
A
response
is
not
expected.
D
I'm
here
let
me
just
hear
me.
F
D
Yeah
so
in
our
case,
we
mainly
use
json,
our
pc
with
mqtt.
We
use
impunity
with
obviously
other
types
of
topics,
but
when
we
use
it
over
when
we
use
json
rpc
over
mqtt,
we
have
a
single
topic
for
requests
and
usually
a
single
topic
for
responses
so
and
basically
and
then
jsonrpc
works
with
basically
different
methods.
D
D
Oh,
no
because
json
rpc
doesn't
it
doesn't
know
about
mqtt
right,
it's
it's
just!
You
can
use
it
over
any
transport,
but
it
doesn't
define
what's
the
behavior
over
mqtt,
so
before
mqtd5,
what
with
mqtt5
there's
the
the
notion
of
re
reply
topic
so
that
helps
a
lot
for
json
rpc
before
mqtt
5
we
were.
We
had
to
do
some
acts
basically
to
make
the
protocol
work
well
over
mqtt,
but
now
it
works.
D
It
works
pretty
well
and
we've
been
basically
trying
to
see
whether
async
api
can
be
used
to
describe
it
because
there's
another
system
called
open
rpc,
which
is
specifically
to
describe
json
rpc
a
bit
like
a
open
api
also,
but
it's
only
meant
to
describe
basically
json
rpc.
So
we
were
interested
in
seeing
whether
async
api,
which
can
describe
all
the
rest
of
our
apis,
also
mqtt,
could
basically
do
both.
B
B
So
yeah
I'll
schedule
another
call
for
next
week,
if
that's
up
for
everyone
and
then
high
code,
if
you
don't
mind,
not
writing
a
conclusion
but
like
assuming
like,
what's
it
like,
called
where
we
left
off
yeah
and
where
we
can
continue
from
yeah,
because
then
it's
easier
to
get
right
into
it.
Yeah.
C
E
Gonna
try
to
to
to
write
an
example
myself,
as
well
of
where
I
meant
now
and
and
yeah,
but.
F
E
Definitely
something
that
needs
more
exploration.
D
Right
sure
I
can
maybe
try
explaining
the
basic
of
the
juicing
rpg,
which
is
pretty
simple,
but
it
may
help.
A
I
suggest
you
do
it
in
the
issue,
because
the
the
request,
like
it's
clear
from
the
owner
of
the
request,
that
he
cannot
be
a
champion
of
the
proposal
any
longer
so
so
definitely
update
the
issue.