Reputation:
I have a service which accepts HTTP requests from a customer site. The service then sends an HTTP request to a transactional email provider with information provided in the initial request to the service. The workflow looks like this:
CustomerSite ⟷ EmailService ⟷ TransactionEmailProvider
I can think of two possibilities for handling requests so that errors from the TransactionalEmailProvider can be reported to the CustomerSite.
EmailService
immediately sends an asynchronous request to
TransactionalEmailProvider
when it receives a request from a
CustomerSite
. The EmailService
immediately responds to the
CustomerSite
with a success code if the request was properly
formed. If a failure happened when sending a request to the
TransactionalEmailProvider
, the EmailService
sends a failure
notification using a POST request back to the EmailService
using a
webhook implementation. Right now I'm implementing the first version because I don't want the responsiveness of the EmailService
to be dependent on the responsiveness of the TransactionalEmailProvider
.
Is this a reasonable way to process HTTP requests that are dependent upon a second level of HTTP requests? Are there situations in which one would be preferred over the other?
Upvotes: 1
Views: 27
Reputation: 17683
Is this a reasonable way to process HTTP requests that are dependent upon a second level of HTTP requests? Are there situations in which one would be preferred over the other?
It really depends on the system requirements, it depends on how you want to behave in case of failure of some of its components or under varying workload.
If you want your system to be reactive or scalable you should use asynchronous requests whenever possible. For this your system should be message driven. You could read more about reactive system here. This seems like your first option.
If you want a simpler system then use synchronous/blocking requests, like your option no. 2
Upvotes: 1