Extending - WAMP protocol

[samson84]

Hi!

I would like to join to the Protocols and Payloads meta issue: Do you have any plans to support the WAMP protocol?

WAMP is an open standard WebSocket subprotocol that provides two application messaging patterns in one unified protocol: Remote Procedure Calls + Publish & Subscribe.

It is basically meaning a support for the RPC + PUBSUB modell, and somewhere a WAMP enum in a some protocol field.

The topic has been discussed in separate threads in the following parent issue:
parent issue #586

[samson84]

Oh, and these guys from WAMP trying to figure out something like this: wamp-proto/wamp-proto#61

[darrelmiller]

It is good to see someone making an effort to standardize an application protocol on top of WebSockets. However, until WAMP makes it out of IETF draft status (especially expired draft status) I would be reluctant to spend any significant effort trying to change OpenAPI to support WAMP.

It is challenging enough attempting to cover all the request/response HTTP use cases without trying to introduce full bi-directional support as well. In many ways I think it would be easier to create a fork of the OpenAPI spec designed specifically for bi-directional messaging protocols and create specific tooling for that spec than try and have one spec address all distributed messaging architectures.

[samson84]

Yes, you have right, this PUBSUB and RPC is not really related to REST and the main goal of the Open API initiative is improve the REST description language.

What do you think, what is needed to start working on this forked bi-directional part of the standard? Do you have a plan to open a working group based on that in the open API committee or it is not a priority at all? Can I help somehow?

[oberstet]

Hi guys, just became aware of this issue as someone contacted me rgd WAMP and IDLs. fwiw, this is still "experimental" in WAMP, but we have been working on a IDL for WAMP that reuses Flatbuffers.

This allows so specify both:

• RPC, eg https://github.com/crossbario/xbr-protocol/blob/eae39f39f8522967752e042c17f5506dd9e9e4dd/work/schema/example1.fbs#L121, including one-shot, streaming results and bidi-streaming RPCs, and
• PubSub, eg https://github.com/crossbario/xbr-protocol/blob/eae39f39f8522967752e042c17f5506dd9e9e4dd/work/schema/example1.fbs#L108

This is standard Flatbuffers IDL with WAMP specific annotations. There is a meta-schema for the IDL which allows to load, store and process schemata programmatically, eg for docs and code generators, eg https://github.com/crossbario/crossbar/tree/master/crossbar/shell/idl

[handrews]

This looks like it is out-of-scope for OpenAPI, but would likely be in-scope for AsyncAPI (they might already support it, I don't actually know). I recommend checking with them!

[oberstet]

This looks like it is out-of-scope for OpenAPI, but would likely be in-scope for AsyncAPI (they might already support it, I don't actually know). I recommend checking with them!

AsyncAPI only provides a channel based messaging semantics at its core, while WAMP provides an application level "procedure call" and "notifications" semantics (RPC & PubSub).

In my eyes, the word "API" in AsyncAPI is misleading, since it is not at the "API level" but a data communications level protocol.

These are very different beasts and while WAMP could be mapped to a lower level transport like AsyncAPI, I don't see any advantage, we already map to WebSocket or raw TCP, UDS or serial ports.

https://wamp-proto.org/routing.html
https://wamp-proto.org/comparison.html

consequently, I've added it as an issue to add to the WAMP comparison page: wamp-proto/wamp-proto#514