CODEWITHSUNDEEP
restrequestapi-design
Ivan Denisovich
Ivan Denisovich

Reputation: 125

Is it OK to change the response depending on the GET request parameters?

Would it be correct if the responses of one endpoint had a different set of fields?

For example:

There is the endpoint - /orders, which returns information about the orders (assume - 42 fields), and that information is displayed on the user's account web page.

At some point, we have another web page that needs (for its own purposes) information about orders that the user has not paid yet. The request would be something like this - /orders?unpaid=True In this case the web page needs only 4 fields instead of 42. Should i put only this four fields in the response or it would be better to keep one response format for any purposes?

Upvotes: 2

Views: 2479

Answers (2)

pirho
pirho

Reputation: 12215

There are no clear guidelines how to handle case like yours and all discussion seems to be quite opinion biased.

However, it seems that you intend to use query param unpaid to optionally filter out all paid orders so it is ok to put as query param in that sense.

But on the other hand it returns different kind of a response - even it might be a subset of a full (paid?) order data. In other words it makes your API a bit unclear if you decide to return different data types based on query param.

So I suggest the following approach:

/orders                       -- always data with 42 fields
/orderSummaries               -- always data with  4 fields
/orders?unpaid=True           -- always data with 42 fields
/orderSummaries?unpaid=True   -- always data with  4 fields

so let the query parameters affect only on filtering & sorting of the result set but not on the type of data you return.

Upvotes: 3

Plabon Dutta
Plabon Dutta

Reputation: 7249

Most of the time, it's not a good idea to take a decision based on a GET request parameter. GET parameters can be manipulated without putting much of an effort. Having said that, there are times when I would use GET parameters to decide what a user sees and that is when I already know what's the outcome of that particular incident is. For example, if a user provides an invalid credential while logging in, my backend already knows that it's invalid. But let's say, I do not have any other way to pass that error message to front end for the user to display. I would then do something like:

https://example.com/login.php?failed_message=Failed!No user found!

We're not taking any decisions here. We just know that if login.php is called with a GET parameter, it must be a failed login. So, we redirect to this URL from backend.

Upvotes: 1

Related Questions