API for transaction list should allow service combination

[valb3r]

Currently, transaction listing API requires us to provide a resource ID, before calling it. It is incorrect as the call may occur for consent first (that does not need consent ID) and then to retrieve the transaction list (with the service session ID and with resource ID). We need to support GET /transactions without resource id for consent initiation only

In other words, something like GET /v1/banking/ais/accounts/transactions should work as a consent provider which then can be reused to do GET accounts and GET transactions.

[valb3r]

@DG0lden: What do you think about this API?

[DG0lden]

The consent can be given to several accounts. The Fintech can ask about transactions of one particular account only. Therefore, to my understanding 'Get transactions' call is possible only after 'get accounts' call, that provide FinTech with a list of accounts and corresponding resources. This resource is not an account resource at bank side, but account resource at our side. It can be or can be not mapped to bank account's resource

[valb3r]

@DG0lden That's true you can do GET /transactions only after GET /accounts. But users can create consent for the transaction list immediately without calling GET /accounts. What happens:

1. GET /transactions - The user creates consent for his (multiple) accounts to allow transaction listing. This consent allows both get accounts and transactions, no resource id is present here.
2. FinTech uses consent created from the above request and does GET /accounts to get IBAN -> resourceId map

[DG0lden]

@valb3r Ok, so this means that we should move accountId from path-paremeter to a Header and build a validation logic around it?

How do you see this logic?

if (accountIdHeaderExists) {
    if (!consentExists) {
        createCosentForTransactions(accountId);
    } else {
        getTransactions(accountId):
    }
} else {
    if (consentExists) {
        returnError();
    } else {
       createConsentForTransactions();
    }
}

[valb3r]

@DG0lden I would simply expose GET /transactions without account id so that we have:

1. GET /transactions
2. GET /transactions/:accountId

GET /transactions would always create consent. This means in pseudo-code:

Object getTransactionsWithoutAccountId(Request request) {
  if (serviceSessionTable.contains(request.getServiceSessionId()) {
     throw new IlegalStateException("Consent authorization is already started");
  }

  // As there is no service session, there is no consent
  return protocol.getTransactionList();
}

[DG0lden]

@valb3r ok, fine for me