Hi Jean-Philippe, > 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.
If you want to add an object to a collection, the proper verb to use is POST. For the case you're taking about, the RESTful HTTP way is to implement a flow like this: Client: POST http://localhost/myapp/car/ [data] Server: 201 Created Location: http://localhost/myapp/car/15 Client: GET http://localhost/myapp/car/15 (if desired) > 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". > 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 I think the typical thing to do would be to have "cars" in the URL in all these cases, not to have a second cars resource. So long as you're consistent it probably doesn't matter. > 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? I don't know if it's the best way, but you can route multiple URI templates to the same resource class. The URI template parameters will be added to the request by the framework. Plus, the default router match mode will match /myapp/car to /myapp/car/{key}/{value} with key=null and value=null. You may not even need to map multiple templates. Rhett On Jan 20, 2009, at 12:47 PM, Jean-Philippe Steinmetz wrote: > 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=1039085
