In your example, you want to change from a pattern such as:
/ws/customers/42/orders/45/lineitems/15
... to a pattern like:
/ws/orders/45/lineitems/15
This seems trivially easy to me, so perhaps I'm missing something ...
but can't you just return an HTTP redirect? You could do this with an
Apache httpd rewrite rule (i.e. one line of code). Clients which request
the old URI will get sent to the new one, and the problem is solved. The
new, simpler, URL includes nothing which wasn't already in the old, more
complex, URL. Now, if you had wanted to migrate from the simple URL to a
more complex URL it would have been more difficult, and this shows why
it's a good idea not to encode more information in a URI than is needed
to actually identify the resource. If in fact you can identify the order
resource without needing to know customer code, then that shows that the
customer code didn't belong in the order's URI.
So I think versioning of URI patterns is not such a big issue ... you
can just use HTTP redirects to handle changes. The big issues in REST
versioning are about versioning the schemas of resource representations,
because it's there (in resource representations) where the bulk of the
complexity in a REST system resides.
On 06/05/11 10:20, Jason Erickson wrote:
> Yes, I understand that (or at least I somewhat do), but what I'm
> talking about is: What if I only understood that after the first
> version of my API - then I understand it even better after the second
> version of my API? How do I evolve that?
>
> On May 5, 2011, at 5:15 PM, Ryan Stewart wrote:
>
>> It seems to me that your problem stems from trying to model
>> relationships in your URIs. I think that ReST purists would say that
>> you don't have URIs properly assigned to your entities. They would
>> probably say that Customer and Order are two separate, possibly
>> related, entities, and LineItem isn't. That being the case, there
>> should be one URI that refers to customers (possibly filterable by
>> orders) and one URI that refers to orders (possibly filterable by
>> customers).
>>
>> On Thu, May 5, 2011 at 5:58 PM, Jason Erickson
>> <jason_at_jasonerickson.com <mailto:jason_at_jasonerickson.com>> wrote:
>>
>> I find the approach of using content negotiation very attractive
>> for one class of problems - i.e. the format of your resource has
>> a new version. However, there is another class of version
>> problems which is: my current scheme from navigating around the
>> URL's sucks and I want to improve it.
>>
>> Say, for example, I have a scheme like this:
>> /ws/customers/42/orders/45/lineitems/15 which will return a
>> particular line item from a particular order of customer 42, but
>> later I decide that orders have to do with more than just
>> customers, so I'd rather have /ws/customers/42 and
>> /ws/orders/45/lineitems/15. If, instead, I have
>> /ws/v2/customers/42 and /ws/v2/orders..., I can do whatever I is
>> my new best thinking on it.
>>
>> This does not resolve the issue, however, that this sort of
>> implies that /ws/v1/customers/42 and /ws/v2/customers/42 are
>> different when in fact they represent the same resource, if
>> possibly a different format. So basically, I don't have a good
>> answer for this kind of issue. Does anyone else?
>>
>
--
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297