Based on the way i've currently constructed my app this may not be possible. If I want to add a resource named car I perform a PUT on a url like http://localhost/myapp/car/ instead of http://localhost/myapp/car/15. This is because I do not want the client to be responsible for managing identifiers (that is what the persistence layer is for). I think Jerome's suggestion will work more favorably here.
Although perhaps there is a better way to handle this type of transaction? I've also noticed that to return a list of some data such as car the typical method is to implement a second resource cars. Perhaps its a matter of taste but I would think it would be simpler for the client user to assume if you do not enter an ID or other search parameter into the URI then it implies a "catch all". For example, GET http://localhost/myapp/car/ returns a list of all car objects GET http://localhost/myapp/car/15 returns the car object with ID 15 GET http://localhost/myapp/car/bodystyle/coupe returns all car objects with body style coupe Would not this be simpler? What are the realistic benefits to actually creating another resource cars? Lastly, is there a standard way to simplify creating resources so that performing GET on http://localhost/myapp/car/bodystyle/coupe doesn't require implementing a separate resource from http://localhost/myapp/car? Instead the /bodystyle/coupe part of the URI just becomes a search parameter of the car resource? Jean-Philippe On Fri, Jan 16, 2009 at 12:24 AM, Karel Vervaeke <[email protected]>wrote: > I'm not sure if this will help you, but in case of a PUT, you already > know the url, issuing a GET to the same url > should (by your implementation) return the same entity body you > presented in the PUT. If you want to retrieve a 'more informative' > representation (i.e. including the 'internal' id), you could add a > query parameter to the url. > > Alternatively (more appropriate in case of a POST) you can return a > 201 Created status code [1] (with Location headers and url's in the > entity body) or a 202 Accepted status code > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2 > > HTH, > Karel > > On Fri, Jan 16, 2009 at 2:37 AM, Jean-Philippe Steinmetz > <[email protected]> wrote: > > Hello everyone, > > > > I'm currently working on my first restlet application and have one big > > question. Typically when I want to persist some data I will not know > certain > > information about it (i.e. the ID of the data). Instead of creating the > > object and searching for it I usually design my DAO to return the same > > object with the missing information filled in once it's been submitted to > > the persistence layer. > > > > I have noticed in building my restlet app that the storeRepresentation > > method does not return any type of data, only a status. Some of the > clients > > that will be using the service would greatly benefit from the DAO style > of > > data creation. So, how can I mimick this behavior in restlet so that a > > successful PUT returns the data back to the client as representation? > > > > Thanks for your time, > > > > Jean-Philippe > > > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1038847
