0

Following is an architecture that is designed to develop a payment platform for an organization(shown as 3rd party). Each and every entity has set of REST APIs. For the time being let's say I'm developing something like Paypal.

enter image description here

I have clearly marked the boundaries by vertical lines(red,blue). There are three parties involved. Payment portal, bank and 3rd party.

  1. Customer can initiate a transaction by log in to the payment portal. Payment portal will invoke the bank's API. Request flow is shown in the picture.
  2. Each and every request and response will go through the ESB and will be logged. If the transaction is successful ESB will update the 3rd party database and inform the payment portal at the same time.
  3. Payment portal will initiate another API call to the ESB to make sure that 3rd party database is updated correctly(not shown in the picture).
  4. At last payment portal will send an acknowledgement to the banks that the transaction has gone the full cycle(not shown in the picture). This is another API call.

The problem is what if the there is a network issue between two parties and it's unable to complete the truncation cycle. How it should be addressed?

Let's assume that network between payment portal and 3rd party is lost once the payment portal initiated the request. Payment portal will not be able to get the response even if the transaction is successful at the bank's end. Once the network is bank online how this should be handled?

I have read below.

Transactions in REST?

Community
  • 1
  • 1
Techie
  • 44,706
  • 42
  • 157
  • 243

1 Answers1

1

First of all you should forget about processing the transaction synchronously.

In the first scenario you initialize a transaction and transaction data - with it's status - with 200 OK code is returned. At the beginning status may be e.g. Started. Then you repeatedly send a GET request to fetch all the transaction data and display appropriate info when its status is changed to e.g. Finished. In this scenario if the connection between client and server is broken nothing bad happens - all the data are kept on the server side and the client behaves as an observer. Summing up, 200 OK code is used along with status of transaction.

In the second scenario the HTTP status code indicates if transaction is finished or not. If transaction is started/submitted the response contains transaction data and it's marked as 202 Accepted. There's no internal status field. You should then repeatedly query the endpoint till 200 OK or 204 No Content is returned (in case of a correct answer) or 4XX (5XX) in case of any failure.

These two approaches are different only when it comes to indicating the fact that transaction is finished or not: via an resource internal field or HTTP status code.

Opal
  • 81,889
  • 28
  • 189
  • 210
  • +1 for the answer. To whom do you refer as client and server here since there are 3 entities? Also if possible could you please elaborate your answer more and provide few links to get more information as well. – Techie Oct 14 '15 at 06:33
  • Payment Portal is client it communicates with 3rd party ESB to this is server from my point of view. I'll try to extend the answer later on. – Opal Oct 14 '15 at 06:34
  • @Techie, could you please clarify the scenario a little bit? Since after rereading I'm not sure who exactly initiates the transaction and monitors its status. – Opal Oct 14 '15 at 10:46
  • Corrected. Customer can initiate a transaction by log in to the payment portal. Payment portal will invoke the bank's API. – Techie Oct 14 '15 at 11:44
  • 1
    Ok, so by *client* I meant the system/page that initiates the transaction. Then it should only monitor/request (observer pattern) the transaction state and if it has succeeded/failed react appropriately. By *server* I mean the only system *client* communicates with. Since there no transactions in REST itself this is the only way to emulate them. – Opal Oct 14 '15 at 12:05
  • What if the network issue between two parties go down, How can each party know? Client might think that it's at the server-end. Server might think that it's still nt sent by the client? – Techie Oct 14 '15 at 12:22
  • 1
    It depends on the libraries used but *client* will receive exceptions or timeouts, that's all clear and secure. *Server* does not initialized the connection to the *client* so there's no problem on this side. If the connection goes down while adding new transaction. In such creating new transaction on *server* side should done itself as a transaction - e.g. DB transaction. After connection is established again *client* will know about the result by querying it. – Opal Oct 14 '15 at 12:26
  • Thanks a lot for the support – Techie Oct 14 '15 at 12:31