Hi Victor,
The query parameter is part of the URI. So from the perspective of the
resource query parameters should be taken into account for conditional
gets for both the server and client.
Clients always need to manage the conditional information with the GET
by sending last-modified or etag information sent from the server in a
previous response to a previous request for the same URI regardless of
whether that URI contains query parameters or not.
Where sometimes query parameters are not taken into account is proxies
that cache content. I am not as familiar as i should be with web
proxies but i think this is more a implementation limitation than
anything specific to HTTP.
So as Kevin recommends query parameters are recommend way to do this.
Especially if such query parameter names are reused for many resources
i.e. it provides a common interface.
Paul.
On Oct 8, 2008, at 6:42 PM, Grazi, Victor wrote:
> Does the scope of this group allow questions on best practices?
>
> I am wondering from a ROA point of view, how to handle this case:
>
> I want to get a sub-resource with many records, for example: /
> resources/portfolios/SandP500
> In the client application, these will be displayed 20 companies at a
> time, a count that is configurable by the user.
>
> I would like to divide the request into pages so as not to require
> returning all 500 pages at a time.
>
> 1. Is each page a different sub resource? That would be structured as:
> /resources/portfolios/SandP500/page1
> /resources/portfolios/SandP500/page2 etc?
>
> That makes it difficult to configure per user, if they want to
> change that to 25 results at a time, etc, it would not scale.
>
> 2. Or do we make it one resource and pass in paging parameters
> /resources/portfolios/SandP500?companies1-20
>
> That makes it difficult to use a caching strategy with conditional
> gets. If I already cached companies 1 thru 20 and the resource did
> not change, but now I need 21 thru 30, it requires the client to
> manage the conditional get?
>
> I guess the second approach makes the most sense - the client checks
> the cache before deciding to make a conditional request, but is that
> the best practice recommendation for this use case? It has a slight
> smell.
>
> Is there a better suggestion?
>
> Thanks, Victor
>
>
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
>
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
>