Unclear ownership of the specification about spec HOT 7 CLOSED

I think in this approach it would be good to include a host and schemes on each topic since a service may accept incoming commands via unencrypted channels (mqtt) but only emit events via encrypted ones (mqtts).

That's a very interesting point. I think we can consider it for the next version. What do you think? How do you feel about contributing to it?

Thanks!

from spec.

I just realised this is particularly necessary when a microservice emits events on a topic and has a endpoint implemented using websockets.

I'll think about that.

from spec.

Also, I think before I didn't get your question totally right. The spec defines what the service (the computer program) does. So when you see subscribe it means the service will be subscribed and listening to this topic. It also means, consumers will need to publish to this topic in order to communicate with the service. So we could say the spec is seen "from the service perspective" and the service is the owner of that spec.

In other words, the spec defines what the API does and not what the API expects you (as a consumer) to do.

It should probably be clearer in the docs.

from spec.

@fmvilas does that mean that if ServiceA publishes to topic A, and there are 10 consumers then all 10 consumers will have to specify that they subcribe to topic A and what are the contents of the message. That would have 11 copies of the same information.

If we look at the world pre-AsyncAPI and imagine 10 service doing HTTP requests to Service A, there's no need to specify on each of those 10 services that they will consume /service-a/endpoint3/:id.

I am missing something... :-(

from spec.

does that mean that if ServiceA publishes to topic A, and there are 10 consumers then all 10 consumers will have to specify that they subcribe to topic A and what are the contents of the message. That would have 11 copies of the same information.

Yes, you'd have 11 copies of the same information. However, if you don't want to copy/paste it, you can always separate the message definition in a separate file/url and link them from all the places. And the definition will just remain in a single place. For instance:

$ref: "http://path-to-my-message-definition/message.yml"

If we look at the world pre-AsyncAPI and imagine 10 service doing HTTP requests to Service A, there's no need to specify on each of those 10 services that they will consume /service-a/endpoint3/:id.

There's no need because communication in HTTP APIs is always started by the client. You make a request and expect a response. However, consider the following example with HTTP APIs: if ServiceA wants to request something to ServiceB, then ServiceA expects a response. If you want to know how the response will be, you would have to grab ServiceB definition from ServiceA to know about it. You will have exactly the same problem. Information is not duplicated but ServiceA is coupled to ServiceB.

It obviously introduces coupling at message level, but it's because the message is shared by many services, and it's actually a dependency of many services. If you're using a message broker the only idea that comes to my mind is that these messages are defined in a "shared messages" project.

If another alternative comes to your mind, please don't hesitate to make a proposal :).

from spec.

If another alternative comes to your mind, please don't hesitate to make a proposal :).

Sure! What is your preferred channels to discuss proposals? Should I go with a full PR directly?

from spec.

I think we should use Github issues because it allows other people to participate too. You can also join the Slack channel: https://async-apis-slack.herokuapp.com/

from spec.