> > > It sounds like you're pushing against the constraints of the REST > paradigm, > > which limit you to exposing at most one GET operation per resource. If > you > > have both GET-by-name and GET-by-identity operations, you need to have > two > > kinds of resource (if you want to be RESTful), which most naturally > > corresponds in Restlet to two ServerResource subclasses. >
> I disagree. It is a common practice to provide multiple urls to the same > resource. Take for instance, the Jenkins (Hudson) CI server. Given a job > MyJob and 535 being the latest build number, then the same resource, namely > the job build #535 is available using two different urls: > - http://bla-bla/jenkins/job/MyJob/12 > - http://bla-bla/jenkins/job/MyJob/lastBuild > > How do I implement this in Restlet using a single ServerResource? This > ServerResource class is going to have a single Get() method and it would be > my responsibility to check whether the url is parameterized with an id or > it is the lastBuild permalink. This is a boring boilerplate code. If the > native Restlet API supported strongly typed request handlers, then I would > have two Get methods: > public BuildBean Get(int id) { return GetBuild(id); } > public BuildBean Get(){ return GetLastBuild(); } > > (Of course, this example limits me to only one permalink, when in fact > there may be more, like lastFailedBuild, lastSuccessfulBuild, etc ... But, > I hope it conveys my point) > > > Another real world example are Mercurial changesets. Any changeset has a > universal identity, which is a string, quite a long string, if I may add. > But in addition to this, any changeset has a numeric id, which is unique > within the particular repository clone. Hence we have a resource, which can > be accessed using two unique keys of different types, which is modeled > rather easily with two Get methods: > public ChangesetBean Get(int id) { ... } > public ChangesetBean Get(string hash) { ... } > Both return exactly the same resource. > > > I do not see how these examples contradict the REST paradigm. If you do - > please explain. > In each case, you **are** describing two different resources. The **representation** returned might be the same at a particular moment in time, but the concepts behind the two resources are very different. I agree with using separate server resources for each. Usually you can choose a canonical URI to GET the representation from, and have others implemented as links: Return 303 and the canonical URI. In the case of the builds, the canonical URI would contain the unique build id, and in the Mercurial example it would probably be the universal id. Mike ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2890200
