CODEWITHSUNDEEP
javajsonrestweb-services
PatPanda
PatPanda

Reputation: 4970

Web service design: should a rest api send back half or all information?

Small question regarding how to respond to a restful web request when having the other half of the information.

I would like to insist this is not an opinion based question, as I believe there should be an optimum answer in terms of what to do.

Scenario: Some client service, SERVICE_A, is some kind of service allowing a customer to buy products. However, SERVICE_A only knows the product. Meaning, SERVICE_A does not know the price of the product, it needs to call SERVICE_B to get the price of the product real time. With that said, SERVICE_A, know only half of the information, knows only the product, not the price of the product.

A customer will select a product via SERVICE_A front end. Customer cannot go to other services. Then SERVICE_A will call SERVICE_B (1) with the product via API. something like :

{
    "product": "someProduct"
}

Then, SERVICE_B will receive the request (2) and will then compute the price with its own algorithm that he knows (3).

Once done, SERVICE_B will return the price to SERVICE_A (4) who now has all the information and can display it to the customer.

My question is, should SERVICE_B send back only his half of the information back to SERVICE_A and let SERVICE_A reconstruct the whole? Or send back both at the same time?

SERVICE_B sends back only the price. SERVICE_A who sends the request reconstruct someProduct = 1.2

{
    "price": 1.2
}

Or should SERVICE_B send back everything.

{
    "product": "someProduct",
    "price": 1.2
}

In my example, I use only one field. But in reality, there are many more. This is just an example.

Again, this is not an opinion question. I believe there should be an answer based on performance, design principle, microservices architecture etc.

Thank you

Upvotes: 0

Views: 179

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57259

My question is, should SERVICE_B send back only his half of the information back to SERVICE_A and let SERVICE_A reconstruct the whole? Or send back both at the same time?

The usual answer in REST is that SERVICE_B is going to respond to the request with a copy of its current representation of the resource that is asked for.

GET /price-list?product=someproduct

In essence, you are asking if the product should be part of the representation, to which I answer:

  • sure, why not?
  • but you don't have to.

If there are "many more" items in the URI, then you can pick and choose which ones you want.

It may help to review chapter 5 of the Fielding dissertation, and in particular his remarks about the cache constraint.

The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions.

In other words, for information that we think is going to be changing slowly, efficiency comes from reducing the number of round trips, not from reducing the size of the response.

Therefore, you'd be more likely to pack extra information into the response (assuming that the caching times remain satisfactory).

Now if, instead of REST, you are using a design with more of an RPC character (SOAP/graphQL/gRPC), then the answer might change, because "caching" loses a lot of its power when general purpose components cannot leverage it.

If there are going to be extra round trips anyway, it can make sense to keep the payloads smaller.

Me, I'd be biased toward including the information provided by the client, because that gives you a means by which you can troubleshoot certain kinds of errors. But that's an "all else being equal" sort of position. If you need small, if you really need it, then you'll need to closely consider the budget when introducing support for trouble shooting.

Upvotes: 1

Related Questions