Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Best way to design URI namespaces with related resources?

Expand Messages
  • Ben Ramsey
    ... [snip] ... I m working on a project in which we faced a similar challenge. The URIs we launched the project with follow your /users/100 and /photos/201
    Message 1 of 4 , Mar 2, 2008
    • 0 Attachment
      On 2/28/08 4:28 PM, jjn1056 wrote:
      > Now the first problem we have is to decide the best way to create a
      > URI hierarchy for photos that belong to users.

      [snip]

      > From a programming perspective we prefer the second choice since it
      > allows us to have a base controller for the photos and then
      > discoverable 'filter' path parts below that which can inherit or
      > enhance the behavior. From our perspective that's a lot better than
      > have to duplicate the photo controller behavior for stuff under our
      > user controller (and again where ever else we end up have sets of photos).
      >
      > What do you think of this choice and reasoning?

      I'm working on a project in which we faced a similar challenge. The URIs we
      launched the project with follow your /users/100 and /photos/201 approach, with
      no hierarchy information for photos belonging to users. However, we are changing
      this.

      We will still maintain the /photos/201 URIs, but they will simply redirect to
      our canonical /users/100/photos/201 URIs. We settled on this structure because
      we believe it conveys the proper hierarchy.

      As far as programming goes, we're using the routing features of the framework we
      use to allow us to keep the same controller structure we currently have, but the
      routes are set up as such that we don't have to duplicate any code.

      > Our second problem has to do how an item that is part of a collection
      > of items (say a particular photo in the big list of photos from the
      > above example) can carry the context of it's containing set and yet
      > meet the needs for canonical uris that seem to be an important part of
      > designing REST websites. Here's an example of what I mean.

      [snip]

      > Now here's our idea of what a similar resource would be like if the
      > user navigated to a photo via a user:
      >
      > GET /photos/201/user/100

      To me, this URI looks as if you are viewing a user resource via a photo and not
      the other way around, as you have suggested. The hierarchy here isn't logical to me.

      In our case, again, we settled on conveying the ownership of the photos in the
      canonical URIs, so in every place that "photos" appear in a collection of items
      (for example, at /photos), they still link to /users/100/photos/201.

      Of course, you can contrast this with flickr, which uses /photos/{username}/201,
      but, in this case 201 refers to the photo resource, which I think is logical.

      --
      Ben Ramsey
      http://benramsey.com/
    Your message has been successfully submitted and would be delivered to recipients shortly.