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

9714Re: [rest-discuss] URL-Design: Structured Resources vs. Searching Globally

Expand Messages
  • Stefan Tilkov
    Nov 1, 2007
      On Oct 31, 2007, at 11:35 PM, Stefan Hübner wrote:

      > On 30/10/2007, Stefan Tilkov <stefan.tilkov@...> wrote:
      > [snip]
      > > I see nothing wrong with having both options -- i.e. /products is
      > the
      > > collection resource for all products, and /companies/{id}/products
      > is
      > > the company-specific one. I assume that in both cases, you'd
      > return a
      > > list of links.
      > OK. So /products would return e.g. XML like
      > <products>
      > <product xlink:href="/companies/1/products/1" />
      > <product xlink:href="/companies/1/products/2" />
      > <product xlink:href="/companies/2/products/1" />
      > <product xlink:href="/companies/3/products/1" />
      > ... and so on, right?

      Yes, or it could be

      <product xlink:href="/products/1" />


      <product xlink:href="/AD5EFFAE132865DDE" />

      or whatever.

      > On my way home just after posting my my first mail, I realized I
      > should look at the application from a Website-point-of-view. Meaning:
      > there can be several lists of similar things in different places of
      > the application. As long as they link to valid documents and clients
      > get what they expect when traversing those links.


      > > Beware of over-emphasizing URI meaning, though -- it's nice to have
      > > readable URIs, but they shouldn't "leak" into your design.
      > Could you please explain your point a bit?
      It's tempting to start first REST projects with obsessive URI design,
      but as Hugh pointed out by now, too, client-side URI construction is
      always a bad sign (unless the client has received instructions on how
      to construct the URI dynamically).

      Stefan Tilkov, http://www.innoq.com/blog/st/
    • Show all 7 messages in this topic