System Design - API Response Translator

Let say I have a service called as User which has getUser() and createUser() APIs.

We have different channel through with these apis can be access like B2B (Partner 1(P1), Partner 2(P2) ...), B2C (Mobile, Web).

Now the use case is the API response can vary based on the channel/partners.

Example: getUser has in total 10 fields. If the api is accessed through B2C web channel, we need to return all 10 fields. If the api is accessed through B2C mobile channel, we need to return 8 the fields. If the api is accessed through B2B channel by partner P1, we need to return 6 the fields. If the api is accessed through B2B channel by partner P2, we need to return 8 the fields.

My question is what would be the best way to achieve this?

Here are few of the approaches which I can think :

1. In user service, we can have one translator which will convert the service DTO object to API response. We can have conditional statement to determine if that field needs to be added in the API response based on channel/partner

• Pros: - Could think any
• Cons:
  • Code manageability would be difficult
  • Dynamic changes in the response(addition/removal of any field) for any channel/partners required service deployment

2. In user service, we can have different translators which will convert the service DTO object to API response.

• Pros:
  • Since translator are maintained at channel/partner level so changes done in one translator won't impact other
  • Follows Single responsibility principle
• Cons:
  • Dynamic changes in the response for any channel/partners required service deployment

3. We can maintain template of response based on different channel/partners in some config service. When the request comes in we will call the config service (can be cached to improve performance) and get the response template and fill the required field info.

• Pros:

  • Dynamic changes in the response for any channel/partners does not required service deployment
  • Onboarding of new partner with custom response would be easier. Does not required any user service level changes

• Cons:

  • Need to manage separate config service

4. The core service (user) will always return all the fields irrespective of channel/partner. We can have an orchestrator layer in between caller and user service which will be responsible for setting the response field.

• Pros
  • Orchestrator layer can be further extended to enable of disable any feature based on channel/partner.
  • User service will have core logic. We don’t need to deploy user service until there is any change in core logic
• Cons
  • Orchestrator layer needs to be maintained separately
  • Need deployment of config service when there is any changes in response for any channel/partner