refactor: 2060 design change post thridpartyrequests transactions #65
Conversation
| @@ -0,0 +1,16 @@ | |||
| title: Party | |||
There was a problem hiding this comment.
Hmm I wonder if we are pigeon holing ourselves here with an entirely new definition of Party for the sake of a couple API calls. Can't we just extend the PartyIdType enum to include THIRD_PARTY_LINK in the 3p API so that everything is compatible?
I think we should just be copying the party definition in here from the FSPIOP-API, and extending PartyIdType.
There was a problem hiding this comment.
@lewisdaly THIRD_PARTY_LINK is already in enum for PartyIdType
There was a problem hiding this comment.
I introduced the whole chain for PartyTPLink to reach the input-validation feature that for POST /thridpartyReqeusts/transactions - elsewhere we need to implement this in code for every service in a chain: api-adapter/scheme-adapter
There was a problem hiding this comment.
what do you prefer -> swagger validation or in code validation?
There was a problem hiding this comment.
Went away and thought about this... and I think I see your point now. This is a way we can get nice, 'strict' typing of our Swagger defs, more so than the API definition itself. In which case I agree this is the right way to go.
sourceAccountId&consentIdfrom POST /thridpartyReqeusts/transactions@lewisdaly please double-check this PR because these are not yet documented changes - maybe I misunderstand something...