2

Here is the situation. System A sends the notification as it completes the work items to System B. System A does not know how many items the project consists of. It's just a pass-through system. System B knows the number of items. Once sys B receives the notification for the last item, it has to wait for the final authorization and send the close-project notice to system A.

My question is should I try to implement the entire communication as:

  1. one asynchronous REST API, or
  2. two synchronous APIs, one for items completion (from A to B) and the other one for the final approval transaction (B to A)?

system A ----------- system B

item 1 done ------------ >

<---------- got it ------

item 2 done ------------->

<---------- got it ------

. . .

item n done ------------- >

<-------------------- ----got it but waiting for the manager's approval. may take weeks.

.... may take days/weeks

< ------------------------Manager signed. The project is closed and here are the details.

Glorfindel
  • 3,167
user1473349
  • 21

2 Answers2

2

An API may be synchronous where low latency is a requirement and asynchronous where data or service availability and connectivity are low. So I would suggest doing it asynchronously because as you say in your example, the final approval(from B to A) may even take weeks.

Sebastian Sotto M.
  • 775
2

With a timeframe of days or weeks you may want to think about what happens if there is a failure while waiting for the confirmation. If you want this to just work and be resilient to the host process being restarted then 2 calls (and saving the current state e.g. waiting for reply) in the database makes sense. You're on your first steps to creating a workflow engine, by the way. If you have many more of these human powered workflows to support it might be worth taking a look at them. Good luck!

Jason Weber
  • 330