Should clients send all required information to servers?

Question

Should a service making a request send all the information another service requires from the requesting service to complete the requested service's job? Or should the requesting service send as little information as possible when making a request and let requesting service decide what additional information to call back for? Or does it depend on the circumstances, like the volume of information needed?

Example

If the requesting service is Venmo and the requested service is Bank of America and the request is to withdraw money from a customer's Bank of America account and send it to another bank account, should Venmo send all the details Bank of America needs to do the withdrawal? Or should Venmo send as little information as possible, for example just Venmo's identifier for the payment request and Bank of America can call back to request additional information about Venmo's payment request?

Additional Information

I'm reading Chris Richardson's advice on Microservices https://microservices.io/patterns/communication-style/messaging.html and he seems to imply that the service that initiates a request should send all the information the service that's responding to the request needs. I see the advantages of that: 1) only one message needs to be passed between the services, which reduces the chances of a failure occurring at some point in the communication, 2) Developers also have one object to look at to know everything about how the services communicate.

However, I've noticed disadvantages in practice: The requesting service may send information the requested service does not need. For example, let's say Venmo passes everything Bank of America needs. Now, Venmo wants to work with a bank in a country with high levels of money laundering. This bank needs not just the ordinary payment request but needs Venmo to send information verifying the identity of the people the payment request is for. Now Venmo has to either modify its standard payment request message to contain the identity verification information or banks that need the additional information need to request it. Now we are in a state where the requested service is requesting information from the requester and our communication flow is not as simple. Instead of having one request that contains most of the information from Venmo, Venmo could provide just an internally generated request id, expose a few APIs, and banks can use whichever APIs they need. It will require more messages between the services, but it takes the responsibility totally off of Venmo except for exposing its data to banks.

Answer 1

Should clients send all required information to servers?

No

Should Venmo send all the details Bank of America needs to do the withdrawal?

Financial institutions (FIs) generally do not interact directly with each other for money movement transactions. They interact with financial networks, such as the ACH (Automated Clearing House) network or the Visa network.

To submit an ACH transaction, an FI would need to submit

• Source RTN and account number
• Target RTN and account number
• Amount
• A short memo field, which can contain a reference number

That's it. There's no information about either bank other than their identifier. It's the responsibility of the clearinghouse to know which ID goes with which financial institution and how to contact them.

To submit a Visa transaction, a merchant can submit a bare minimum of

• Merchant identifier
• Card number
• Amount

A merchant might also submit

• Cardholder name
• CVV
• Expiration
• Postal code
• Full address
• Phone number

The reason for submitting the additional information is not to save the Visa network data retrieval operations. The Visa network will retrieve that information regardless. The additional fields are additional authentication parameters, fed into a risk engine and compared against the correct values; the transaction is accepted or declined depending on the risk level (the reality is more complex than this explanation but this is the gist of it).

So in both cases, other than the information the caller needs to provide to signal its intentions, the APIs are getting their own information from their own trusted sources. The reason for this is pretty obvious-- if they just trusted the caller, the information could be incorrect, and could constitute an insecure direct object reference, which is a security vulnerability.

In general APIs should require only the minimum parameters they need to understand the caller's intent. The API itself is responsible for getting any supporting information.

Answer 2

I don't presume to know what the linked article thinks, but there may be two different things here.

According to REST the client should send all the information the server requires to process the request. However, this is a technical requirement, not a semantic one. It means that the request should carry its type and all the contextual information needed, specifically not relying on previous communication, so that the server knows how to deal with it technically.

The server may very well "deal" with the technically complete request by asking back: hey, I need some more data to semantically complete the request. Or by directing you to log in. Or issuing an error related to the meaning of your request. Those are all considered technically "handled" requests.

Note however, if the server asks an additional question (pops up another form, etc.) the next request needs to contain all information until this point in the conversation again. I.e. requests should be stateless and not rely on previous communications.

Beyond these technical constraints, what the request really means, what it contains specifically, what the workflow is, if any, is up to you.

Answer 3

If you're going Microservices, keep them Micro.

Assume we have two banks, B1 and B2, with wildly different APIs.

One can be online while the other isn't. Updates to them will be done at different times. They have different request procedures.

So, break your services up:

WithdrawMoneyService is the general service for taking money out of banks accounts. It either calls one of those:

• WithdrawMoneyFromBank1Service
• WithdrawMoneyFromBank2Service

Which, in turn, know how to talk to their specific banks (and only to those specific banks), and send only and all the information needed by that bank to make that specific requests.

If a third bank is added, then a third service is raised:

• WithdrawMoneyFromBank3Service.

And so on.

Keep your microservices Micro. If they're having to the same thing in two different ways, that's a strong smell that they might have to be broken into more, smaller services.

Answer 4

The difference is performance and security. If you send a limited amount of data, a fake server (like a real one) would have to send a request back, and you might be able to detect it is fake. I think this is not a great advantage, making sure you are talking to the right service should be done independent of your code.

If you send all the information you think is needed, that might be too much; you might send unneeded data which is just waste of time. If you don’t send everything needed, you have one added data round trip.

I would try to send exactly the data that is needed, and log requests to send more data. Then update the code if some data is regularly needed and not present. But if you send 1000 requests and 50 ask for missing data, that’s not optimal but not that important to fix.