I'm having a hard time following. But, being a baby RESTafarian, I
noted a couple of design issues which I think might help you. Maybe you
already know these principles though:
a) GET should NEVER! change the state of an object. I'm confused as to
how/why you are mixing a DELETE operation and a GET operation together.
I'm probably mis-reading.
GET should only retrieve a representation. Usually, most GET requests
have some sort of candidate-key associated to them (in the URL string)
that can uniquely identify the resource. All you should have to do is
start querying your database. If at the point in time you perform the
query, the record is not in the database, the query result will tell you
this (the size of the result set, or other means).
So, just simply retrieve the object. If it's in the database, great.
Return 200. If not, return 404:
if (someDAO.get(id) == null) {
response.setStatus(404);
response.setEntity(null);
return;
}
b) DELETE should NEVER! return a 404. Your server should be happy to
accept DELETE requests to any (logical) resource, whether or not that
resource actually exists or not.
This comes back to the basic definition of REST: Representational State
Transfer. When you delete a resource, you're really asking that the
state of the resource be moved into the 'deleted' state. If a resource
is already in the deleted state, that doesn't matter.
More generally speaking, a request to change the state of a resource
doesn't depend on the current state of the resource. This is the case
whether the call is a PUT or a DELETE. A PUT that updates a resource to
the exact same value still returns a 204 No Content status. Same thing
with a DELETE to an already deleted record, it still returns 204 No
Content status (or at least a 200 OK status).
Anyway, like I said, I was having a hard time following your message.
Maybe you could be more specific about what you're trying to do instead
of speaking in general terms.
Just let your transactions come in which ever order they come in. If a
GET comes before a DELETE, or vice versa, that's ok. I think you're
trying to tie the two together or something?
Hope this helps,
Adam
Geoffrey Wiseman wrote:
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.
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).
