It seems like in the section about Long-Running tasks, you're describing a pattern that would and could be better served by message queuing. This is great because long running tasks can happen in the background without forcing your customer to wait since this is asynchronous. My team uses the pattern:
Receive the request.
Gather any other data needed.
Send the message to the message broker to be queued.
API responds with a 202 - Accepted and a JSON body that contains a URL that a client can "poll" for status if necessary.
Meanwhile, the message is sent by the broker to a waiting "worker" that will process the message and perform any sort of updates needed to the application/service backing store to let anyone interested know that the work has been done.
It seems like in the section about Long-Running tasks, you're describing a pattern that would and could be better served by message queuing. This is great because long running tasks can happen in the background without forcing your customer to wait since this is asynchronous. My team uses the pattern:
202 - Acceptedand a JSON body that contains a URL that a client can "poll" for status if necessary.Meanwhile, the message is sent by the broker to a waiting "worker" that will process the message and perform any sort of updates needed to the application/service backing store to let anyone interested know that the work has been done.
Yes, I can recommend this practice too.