Van Boris Lublinsky. En dat is weer gebaseerd op deze post van Arnon Rotem-Gal-Oz (jazeker).
De laatste zegt:
"Let's look at message exchange patterns for instance. REST over HTTP support the request/reply pattern.
This works extremely well in many business situation. For instance is we have an Order service (or resource for that matter) and we need to calculate the discount for a specific customer we can go to the Customer service and get her current status and check if she a VIP customer, senior citizen etc.
There are, however, places where it doesn't work as smoothly. Returning to our Order, lets consider what happen once the order is finalized and we need to both start handle it (notify the warehouse?) and Invoice it
The order service does not care about these notifications it isn't its business.
My favorite way to solve this is to introduce business events (incorporate Event Driven Architecture) so that the interested parties will get notified. Another common way to solve this is to introduce some external entity to choreograph or orchestrate it (BPM etc.) both options have different constraints and needs compared with REST. In my organization we have a lot of processes that lend themselves to event processing much better than they do REST over HTTP (though the implementation might end up aligned with the REST architectural style - I am not sure yet)"
Hmmm. Waarom is die Order niet geinteresseerd in bijv. de handling in het warehouse of de invoicing?
Ik snap wel dat er situaties zijn waarin REST niet lekker werkt, maar dit is een onzinvoorbeeld.
Abonneren op:
Reacties posten (Atom)
Geen opmerkingen:
Een reactie posten