The imports-request-reply
world extends imports
by including the request-reply
interface.
This allows the component to perform request/reply messaging patterns.
- Imports:
- interface
wasi:messaging/types@0.2.0-draft
- interface
wasi:messaging/request-reply@0.2.0-draft
- interface
wasi:messaging/producer@0.2.0-draft
- interface
A type alias for list> to represent metadata attached to a message
string
A type alias for string to represent a message topic
A connection to a message-exchange service (e.g., buffer, broker, etc.).
Errors that can occur when using the messaging interface.
-
The request or operation timed out.
-
An error occurred with the connection. Includes a message for additional context
-
A permission error occurred. Includes a message for additional context
-
A catch all for other types of errors
self
: borrow<client
>
- result<_,
error
>
- own<
message
>
The topic/subject/channel this message was received on
self
: borrow<message
>
An optional content-type describing the format of the data in the message. This is sometimes described as the "format" type
self
: borrow<message
>
Set the content-type describing the format of the data in the message. This is sometimes described as the "format" type
self
: borrow<message
>content-type
:string
An opaque blob of data
self
: borrow<message
>
Set the opaque blob of data for this message, discarding the old value
self
: borrow<message
>data
: list<u8
>
Optional metadata (also called headers or attributes in some systems) attached to the message. This metadata is simply decoration and should not be interpreted by a host to ensure portability across different implementors (e.g., Kafka -> NATS, etc.).
self
: borrow<message
>
- option<
metadata
>
Add a new key-value pair to the metadata, overwriting any existing value for the same key
self
: borrow<message
>key
:string
value
:string
Set the metadata
Remove a key-value pair from the metadata
self
: borrow<message
>key
:string
The request-reply interface allows a guest to send a message and await a response. This interface is considered optional as not all message services support the concept of request/reply. However, request/reply is a very common pattern in messaging and as such, we have included it as a core interface.
#### `type message` [`message`](#message)
#### `type error` [`error`](#error)
#### `resource request-options`
Creates a new request options resource with no options set.
- own<
request-options
>
The maximum amount of time to wait for a response. If the timeout value is not set, then the request/reply operation will block until a message is received in response.
self
: borrow<request-options
>timeout-ms
:u32
The maximum number of replies to expect before returning.
self
: borrow<request-options
>expected-replies
:u32
Performs a blocking request/reply operation with an optional set of request options.
The behavior of this function is largely dependent on the options given to the function. If no options are provided, then the request/reply operation will block until a single message is received in response. If a timeout is provided, then the request/reply operation will block for the specified amount of time before returning an error if no messages were received (or the list of messages that were received). If both a timeout and an expected number of replies are provided, the function should return when either condition is met (whichever comes first)—e.g., (1) if no replies were received within the timeout return an error, (2) if the maximum expected number of replies were received before timeout, return the list of messages, or (3) if the timeout is reached before the expected number of replies, return the list of messages received up to that point.
c
: borrow<client
>message
: borrow<message
>options
: option<own<request-options
>>
Replies to the given message with the given response message. The details of which topic the message is sent to is up to the implementation. This allows for reply-to details to be handled in the best way possible for the underlying messaging system.
Please note that this reply functionality is different than something like HTTP because there are several use cases in which a reply might not be required for every message (so this would be a noop). There are also cases when you might want to reply and then continue processing. Additionally, you might want to reply to a message several times (such as providing an update). So this function is allowed to be called multiple times, unlike something like HTTP where the reply is sent and the connection is closed.
- result<_,
error
>
The producer interface is used to send messages to a channel/topic.
#### `type message` [`message`](#message)
#### `type error` [`error`](#error)
#### `type topic` [`topic`](#topic)
----
Sends the message using the given client.
- result<_,
error
>