Thanks again for everyone's input.
I re-read through some of the REST docs and realized my misunderstanding of
the PUT/POST methods. For simplicity I think the idea of mapping the URI
pattern /cars/{id} to the singular resource implementation and /cars to the
plural will be sufficient; with PUT supported in the singular and POST
supported in the plural. This seems to be the proper RESTful approach?
As for my lists I can definitely see the merit in including only references
to objects instead of a complete list when that collection becomes large. I
am also quite certain that my application will see an increasingly large
number of objects within it's lifetime. However, the clients utilizing this
service will be strictly machines and in some circumstances may benefit from
a complete representation list. So maybe it would be beneficial to create an
attribute called mode that could have the values "full" or "lite" that would
return a list accordingly.
I'll try and give an example of where this situation may be useful.
Unfortunately I cannot discuss the actual data we are working with (due to
confidentiality) so I will try and make the car analogy fit as well as
possible. Let's say i'm writing a visualization system where I have a car
that is composed of N number of graphical assets. My visualizer would query
the service for all assets that make up a particular car. By obtaining the
full list of assets the visualizer can immediately begin drawing the car
without having to perform a look up for each asset.
On Wed, Jan 21, 2009 at 11:38 PM, Rhett Sutphin
<[email protected]>wrote:
> > 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 <
> [email protected]
> > > 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
>
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1043509
