4418Re: [rest-discuss] Re-using information fields for queries in REST
- Jun 1, 2004
----- Original Message -----
From: "dorchard100" <orchard@...>
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
| 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?
| 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.
| Dave Orchard
- << Previous post in topic Next post in topic >>