> If you are both suggesting using POST to add an entry why use PUT > then? It seems to make PUT somewhat irrelevant unless performing an > update.
PUT is useful for updates. It's also useful when the client determines the resource's URL. This latter case is pretty common -- some systems don't expose their internal IDs in the URI, but rather use an identifier which is shared between the client and the server. In that case, the client already knows what the URI will be, even before it is added to the system. E.g., in the main application I work on, one of the central concepts is a study template. Studies have an externally assigned identifier which is defined before either the server or the client has anything to do with the template, and can never change. We use that assigned identifier in the URIs. This has the benefit of making the URIs easier to read and allowing clients to not have to distinguish between creates and updates. > The way you define a list below would require some extra processing > that I don't necessarily do when working with serialization. I don't want to speak for Donald, but I think he was just providing an example representation to make his suggestions more concrete. You should tune your representation to the requirements of your application, of course. Rhett On Jan 21, 2009, at 12:56 PM, Jean-Philippe Steinmetz wrote: > Thanks for all the help. > > If you are both suggesting using POST to add an entry why use PUT > then? It seems to make PUT somewhat irrelevant unless performing an > update. > > I'm going to have to do some rethinking. I'm mainly using this rest > service for passing serialized objects back and forth between the > service and clients. I had originally imagined that the difference > between the cars and car was merely that car returned a single full > car object (serialized of course) while cars returned an array or > list (also full objects) but I can see where you'd think otherwise. > The way you define a list below would require some extra processing > that I don't necessarily do when working with serialization. Has > anyone else come across this kind of a scenario? > > Jean-Philippe? > > On Tue, Jan 20, 2009 at 6:45 PM, Donald S Strong > <donald.str...@transport.vic.gov.au > > wrote: > Hi Jean-Philippe, > > > 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. > > I agree with Rhett, use POST and then GET. > > POST http://localhost/myapp/car creates the car object with a new > ID and > redirects to the URI > GET http://localhost/myapp/car/15 returns the car object with ID 15 > > > 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". > > Would not this be simpler? What are the realistic benefits to > actually > creating another resource cars? > > A "single car" and "a list of cars" are logicaly different > resources; the > structures they return are quite different. > A list of cars will probably contain many URIs, each refering to a > single > car. > eg. > <cars bodystyle="coupe"> > <car name="Bob's car" refid="/myapp/car/15" /> > <car name="Bert's car" refid="/myapp/car/16" /> > <car name="Ernie's car" refid="/myapp/car/132 /> > </cars> > > You may have other resources that also refer to the car URIs. > GET http://localhost/myapp/vehicles returns a list of all bike, car > and > truck objects. > > > 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? > > You can use the same resource implementation if it takes parameters. > Theoretically these are different resources, but in practice they > can use > the same implementation class. > > GET http://localhost/myapp/cars returns a list of all car objects > GET http://localhost/myapp/cars?bodystyle=coupe returns all car > objects > with body style coupe > GET http://localhost/myapp/cars?color=blue returns all blue car > objects > > Regards > Donald. > > > ********************************************************************** > Any personal or sensitive information contained in this email and > attachments must be handled in accordance with the Victorian > Information > Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988 > (Commonwealth), as applicable. > > This email, including all attachments, is confidential. If you are > not the > intended recipient, you must not disclose, distribute, copy or use the > information contained in this email or attachments. Any > confidentiality or > privilege is not waived or lost because this email has been sent to > you in > error. If you have received it in error, please let us know by reply > email, delete it from your system and destroy any copies. > ********************************************************************** > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1040074 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1042906
