1

Currently, I have a rest API service which serves to many different consumers. One of the endpoints of API is for retrieving an order. Inside a single application, I am making 5 different service calls to other external API's to generate and return the response to the caller.

Half of my API's consumers do not need the response of the 3 other services (there are 5 external service calls in total to generate the response). Some of them only want to see the basic information about the order. For those consumers, only 2 API call is enough to generate their content on their side.

However, for the rest of the other consumers, they do use the entire response

Sometimes, because of that, the response time increases rapidly. Even though the consumer does not want to use the response of the specific service, they have to wait for that service in any case.

Is there a way to determine which services should we call depending on the consumer's request?

Shortly, I want my system to determine which service needs to be called depending on the consumer of the API.

note: application is monolithic. it is not a microservice. all 5 API calls are being done within the same application.

Improve this question
4
  • 1
    Could you extend the API so that the clients/consumers are able to specify what kind of response(s) they would like as part of the request? For example, as something in the query parameters (or in the body of the request if your request has a body)
    – Ben Cottrell
    Feb 17, 2020 at 13:33
  • it seems like one would have to know the reasons why certain information is only needed for certain requests, and how they are different. That information is not included in the question?
    – Martin K
    Feb 17, 2020 at 13:54
  • Thank you for your reply. Maybe, for some attributes which contain fewer attributes in the response body, then I can tell consumers to specify which fields will be included within the body in the request header. For the responses which contains much detailed objects and attributes, I can let them send the required fields inside the request body then. What if they send the context schema in advance so that they do not need to specify it all time? I think that's could be a more feasible approach, just thinking @BenCottrell
    – Ekin Yücel
    Feb 17, 2020 at 14:16
  • Thank you for your reply. If I understand it correctly, you mean the domain experts right? They need to decide which fields should be returned for specific requests. In this case, I need to contact my consumers anyway in terms of which fields do they need exactly. @MartinK
    – Ekin Yücel
    Feb 17, 2020 at 14:20

1 Answer 1

Reset to default
0

You have a great use case for GraphQl's "ask for what you want" approach. Unfortunately you'd have to break with REST's ubiquitous-ness and rewrite the client and server parts.

JSON:API has formalized another approach that I like, related resource links. In this approach, links to related resources the server anticipates the client will need can be included. The related objects themselves can also be included. You don't need to use JSON:API to do it this way, but they have it written out how to do it very neatly.

You would want to split your objects, like /users/:id/address etc. if say address was the part that was expensive to return.

Improve this answer
1
  • Thank you for your answer. I will investigate more about related resource links. For the frontend service calls, I would choose GraphQl approach. However, for the rest of the service calls, I am planning to implement some kind of facade style gateway in front of the services
    – Ekin Yücel
    Feb 24, 2020 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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