Hello Geoffrey,
If you've got a resource that handles GET and DELETE and has one or more
representations that require a certain amount of effort to instantiate, but
might 404 based on information out of the database, what's the usual pattern to
handle this?
On the one end of the spectrum, I could create both representations in the
constructor, but this create performance load when it might simply be a DELETE
call that doesn't need either representation directly.
A resource's constructor is not required to create representations,
that's the aim of the method "Resource#getRepresentation(Variant)" which
generates a representation of the resource (i.e. data) according to a
variant (i.e metadata such as media type, language, etc.).
A resource's constructor is responsible to lists all managed variants
(in the getVariants() list), which allows the content negociation
algorithm to compare the metadata accepted by the clients (the "Accept
headers"), and the metadata of the representations generated by the
resource.
On the other, I could hold off from touching the database until such time as I'm
in delete() or getRepresentation(Variant); but I'm not sure if I can 404 from
these. This seems like the performant approach, but I'm not sure if fits with
the way Restlet is designed.
Then, in the middle somewhere, I could verify the record exists for GET or
DELETE in the constructor, put in the variants, and then handle delete() and
getRepresentation(Variant) through another call to the database. This requires
me to make two calls (or hold a database connection / recordset / session open
between the two).
1/ your resource's constructor defines all types of representations
potentially supported by the resource:
e.g.:
getVariants().clear();
getVariants().add(new Variant(MediaType.APPLICATION_XML));
etc...
2/ the "delete()" method is in charge to access the database and perform
the deletion
3/ the "getRepresentation(Variant)" is in charge to return the
representation of the resource according to the variant that best fits
client's requirements.
I hope this will help you,
Thierry Boileau
p.s.: DELETE method does not return 404 according to the HTTP rfc:
"A successful response SHOULD be 200 (OK) if the response includes an
entity describing the status, 202 (Accepted)
if the action has not yet been enacted, or 204 (No Content) if the
action has been enacted but the response does not
include an entity."
