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?
>