Ah, I see your problem. I think more or less what Conal said in his post.
Figure out what the right URIs are, and just add them. Keep the old ones for
backward compatibility. Make them return a 301 redirect to the new URI.
On Thu, May 5, 2011 at 7:20 PM, Jason Erickson <jason_at_jasonerickson.com>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>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?
>>
>>
>