API vs Event in Microservice approach

 

What about Smart endpoints and dumb pipes in terms of different type of requests?

After reading that I was thinking that it's enough to subscribe for some events and deal with that. But now I've realised that sometimes you should have opened API (maybe not for the end customers, but for the API Gateway etc). Is this ok? Or you should "eventize" (transform into event) any request which coming to Microservices cloud?

So, for instance, you have Invoice and Order services. It's clear that when order created you might use an event which might be consumed by Invoice service to create an invoice. It's clear that for receiving list of last user's orders you may use CQRS on Order service side or even just make new service LastOrders which will keep just projection of required data. But should this request transformed into event or LastOrders should provide API for that and listen for events to update it's own DB?

We do it like this:

  • All commands are issued as messages in durable queues with type-based routing
  • Processing takes places in isolated handlers
  • REST POST and PUT are only created for the API that should be accessible from legacy/external systems
  • These "command"-style REST endpoints only form command as a message and send it via the message bus
  • REST GET is perfect for fetching the data and we do not use messaging there, although we could have some message handlers to retrieve data for long-running processes that can only use messages
  • Command (message) handlers always publish events about what they have done or not done
  • Downstream event processing can do whatever they want by subscribing to these events
    • 链接地址: http://www.djcxy.com/p/34084.html

    上一篇: API网关层

    下一篇: API与微服务方法中的事件