> Another FAQ is how to indicate service version desired by a client in
> a client request.
> Should it be encoded in the path of the URL as in:
> /acme/search/1.0?keywords=foo;bar
> or should it be an option within the URL as in:
> /acme/search?keywords=foo;bar&version=1.0
> Is one better than the other and if so why?
> --
> Regards,
> Farrukh
The query string is meant to act as a filter on the data. Since the
version parameter is not used for this purpose, but to determine which
service should be accessed, the version can better be encoded in the
URL path. IIRC, this is also done in "RESTFul Web Services".
A version parameter in the query string would be more suitable if you
have different versions of data in the same dataset, and you want to
get a snapshot of a certain moment, or something similar. (This is
like the featureVersion parameter in a WFS-GetFeature request.)
Does it matter to the client which version should be accessed? Is the
interface of version 2.0 different than version 1.0, and no longer
backwards compatible? When you need to distinguish between multiple
versions, it is maybe better to set up some kind of Capabilities
document, in which URL's (resources) are given to the different
versions. This will probably be useful if you need to do version
negotiation. Perhaps it's interesting to discuss how an OpenSearch
description document can be extended this way.
Farrukh Najmi wrote: > Another FAQ is how to indicate service version desired by a client in > a client request.
> Should it be encoded in the path of the URL as in:
> /acme/search/1.0?keywords=foo;bar
> or should it be an option within the URL as in:
> /acme/search?keywords=foo;bar&version=1.0
> Is one better than the other and if so why?
If search were the only resource, there wouldn't be much difference. If you had several related resources it would be sensible to collect them under a version, to simplify description and linking if for no other reason.
