Should a service making a request send all the information a 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?


If the requesting service is Venmo and the requested service is Bank of America and 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 a 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, lets 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 identify 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.

  • keep in mind .. it creates a circular dependency within the API call.. e.g If Venmo calls "Bank of America", which in turn calls Venmo... if Venemo server response becomes latent then it will inturn makes "Bank of America" API call latent due to circular dependency.... And with large number of parallel request it can become a big problem.. Hence i don't recommend circular dependencies. Oct 20 at 12:36

2 Answers 2


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.


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.

  • I"m looking for evidence and advice on architecture best practices.
    – user7340
    Oct 19 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.