Hello Jerome, thank you for your reply. [...]
> > limited to individual files: add (POST), replace (PUT), > > delete (DELETE) > > IMO, the PUT should be mapped to both "replace" and "create", unless you > want the server to control the URI of the created resources (via a POST to a > list resource, followed by a PUT to the target resource). > This makes sense to me. Prior to your response, I had already gone ahead and implemented PUT, POST, DELETE. For the POST, I was confronted with the issue you touch on. I introduced a custom header (X-Target-Location) used to specify the filename portion of the intended new resource, and only accept POST requests for directory (i.e. collection) resources. Part of my motivation for using separate methods for create vs. modify was to avoid inadvertent overwriting of an existing resource - when the intent is not to update the resource, but rather to create a new one. Perhaps that was misguided. I would now consider the following: - Map PUT to both "replace" and "create named" - Optionally, map POST to "create auto-named" / "create collection item", i.e. allow the server to control the URI (in this case, filename). [...] > > - if not present, uses */* MediaType > > Maybe "application/octet-stream" would be better here? > Done, thank you. [...] > > How should I proceed to allow PUT, DELETE, POST? > > Override put(), etc. in my SVNResource class? > > If you are using Restlet trunk (future 1.1), you should override the new > methods: > - acceptRepresentation(Representation entity) for POST > - setModifiable(boolean modifiable) for PUT > - removeRepresentations() for DELETE > - set/isModifiable() to indicate if POST/PUT/DELETE are allowed > I started with the release version, and had proceeded to override: put(R), post(R), delete(), allowPut/Post/Delete() So with this new level of redirection, it looks like I would simply rename my existing methods to the appropriate store/accept/remove ones. Got it. What main benefits are there for me in upgrading to the (future 1.1) version? Additional question: I'd like to have all requests to directory resources redirected if they do not end with a trailing slash, such that they do ... I think Directory already does this. It would help me to have a plain english (rather than source) explanation of how I should approach this (presumably in my Finder subclass)?
