Dusan Kasan
Dusan Kasan

Reputation: 83

Different representations of one resource

When i have a resource, let's say customers/3 which returns the customer object and i want to return this object with different fields, or some other changes (for example let's say i need to have include in customer object also his latest purchase (for the sake of speed i dont want to do 2 different queries)).

As i see it my options are:

In the first option there is distinct URI for the new representation, but is this REALLY needed? Also how do i tell the client that this URI exist?

In the second option there is GET parameter telling the server what kind of representation to return. The URI parameters can be explained through OPTIONS method and it is easier to tell client where to look for the data as all the representations are all in one place.

So my question is which of these is better (more RESTful) and/or is there some better way to do this that i do not know about?

Upvotes: 0

Views: 100

Answers (2)

Chris Broski
Chris Broski

Reputation: 2550

There is a misconception that making query parameters look like file paths is more RESTful. The query portion of the address is included when determining a distinct URI so the second option is fine.

Is there much of a performance hit in including the latest purchase data in all customer GET requests? If not, the simplest thing would be to do that so there would neither be weird URL params or double requests. If getting the latest order is a significant hardship (which it probably shouldn't be) there is nothing wrong with adding a flag in the query string to include it.

Upvotes: 0

amphibient
amphibient

Reputation: 31368

I think what is best is to define atomic, indivisible service objects, e.g. customer and customer-latest-purchase, nice, clean, simple. Then if the client wants a customer with his latest purchases, they invoke both service calls, instead of jamming it all in one with funky parameters.

Different representations of an object is OK in Java through interfaces but I think it is a bad idea for REST because it compromises its simplicity.

Upvotes: 1

Related Questions