Properly model Bindings in AsyncAPI

[Yuutakasan]

For example, in the case of Kafka's Server Binding

servers:
  production:
    bindings:
      kafka:
        schemaRegistryUrl: 'https://my-schema-registry.com'
        schemaRegistryVendor: 'confluent'
        bindingVersion: '0.4.0'

but currently there is only one Binding type and it is defined as follows

• name: Binding
  traits:
  • Extensible
    properties:
  • name: '*'
    type: any
    propertyOrder:
  • $this
  • $Extensible

No restrictions.

I would like to add individual restrictions, but is there a naming convention here?

A sample is provided below.
I would like to make a sample if this is acceptable.

KafkaServersBinding
KafkaChannelBinding
KafkaChannelTopicConfigurationBinding
KafkaOperationBinding
KafkaMessageBinding
https://github.com/asyncapi/bindings/tree/master/kafka

[EricWittmann]

Yes bindings do need a bit more work (modeling), for sure. I think the naming convention should be driven by the text of the AsyncAPI specification. For example, the spec has a table of Operation Bindings like this:

So I think the convention should be to remove non-alphanumeric characters from the value in the Type column of that table. So in this case, it would be:

• HTTPOperationBinding
• WebSocketsOperationBinding
• KafkaOperationBinding
• AnypointMQOperationBinding
• AMQPOperationBinding
• AMQP10OperationBinding

And so forth.

I believe this is consistent with your suggestion, so I agree. :)

[Yuutakasan]

@EricWittmann
Sorry for the delay. I will try to work with our team on the Binding extension.