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

4418Re: [rest-discuss] Re-using information fields for queries in REST

Expand Messages
  • Walden Mathews
    Jun 1, 2004
      ----- Original Message -----
      From: "dorchard100" <orchard@...>
      To: <rest-discuss@yahoogroups.com>
      Sent: Tuesday, June 01, 2004 1:33 PM
      Subject: [rest-discuss] Re-using information fields for queries in REST

      | Hey all,
      | I was wondering about the best way to RESTfully model information
      | retrievals versus queries in REST. Imagine an Artist structure with
      | name, genre, albums, rating, etc. I want to both search for Artists
      | that approximate the name or albums, or exactly match a genre or
      | rating. As well, I want to retrieve a given Artist's information.
      | The retrieval is easy, with something like GET /Artist?
      | name=thieverycorp retrieving the structure.

      That looks more like a collection or subset to me. A single
      artist resource might be more like /Artist/123. An important
      question is: how does the client discover that URI? The "hyptertext
      engine" constraint of REST really wants it to be discovered, not
      fabricated by client as a parameter list.

      | But then if want to do a search, I was thinking the best rest way of
      | modeling is to make a Query structure that contains all the Artist
      | queryable information, maybe it's even the same type, and then have
      | an ArtistList resource. Then I could say that any of the ArtistQuery
      | fields can be put in the URI, ie
      | GET /ArtistList?name=thieverycorp or GET /ArtistList?albums=blue.

      I would have called it /Artists?prop=value,..., but that's just
      naming preference.

      | I can't see a way of using the same URI base for both retrievals and
      | queries without doing some funky parameters in the URI.

      URI's are cheap, and so then are URI bases. Why the need
      for such economy?

      There's a
      | variety of other techniques, like appending the requested return type
      | (GET /Artist?name=thieverycorp&type=ArtistList), the number of
      | results to return (GET /Artist?name=thieverycorp&rows=1), etc. but
      | they all seem a bit .... goofy.

      All stemming from a false sense of URI conservation, right?

      If your application really needs to hide the distinction between
      a single resource and a collection of that resource "type",
      then you could try an Alloy trick: treat instances as singleton

      That would mean there are only queries, no retrievals (to use
      your lingo), and when a query returns a single result, blow right
      past the list representation to the individual. I don't know how
      RESTful or unRESTful that would be. I suspect it's neither.

      | Any help on the best way to model this would be appreciated. I'm
      | pretty sure this is almost an FAQ kind of question, so even a pointer
      | would be great.
      | Thanks,
      | Dave Orchard

    • Show all 23 messages in this topic