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=1041749

Reply via email to