ReSTfull depreciation of row entries

In the design of a replacement application that I am working on it is
required that certain historical data be retained. Similar to the idea
embodied in “acts as versionable”, the technique used in the existing
application employs the columns/fields of “date_effective_on” and
“date_superseded_after” which we are retaining in the replacement
application as this technique simplifies other parts of the code.

My question is: what is the suggested method/reSTful routing to
accommodate depreciating existing rows? There are two situations to
consider:

In the first case, the current row is replaced with a new row. In this
situation I conceive that the action is equivalent to http new and that
the controller action of posting a replacement row will check for the
existence of an active current row with the same natural key and, if one
exists, set the “date_superseded_after” on that row to the day before
the new row’s “date_effective_on”, and then update both rows in a
transaction.

In the second case, the current row is simply depreciated and no
replacement data is provided. The required action is simply to set the
“date_superseded_after” to some arbitrary date and update the record in
place. Clearly an http put but what to call the method? It is not a
delete and it is conceptually different than a simple update of column
contents which, in general understanding, implies that the row itself
remains active.

I considered overloading the delete method to accomplish this but my
fear here is that end users, who are aware that historical data remains
available when depreciated, may inadvisedly extend this understanding of
delete into other areas of the application where a delete really does
mean destroy data.

So what to put in place of <?> in "https://was.domain.tld/{collection}/{id}/<?>"? I am thinking “expire”
but I am not sure that making up a new method name is in keeping with
the concept of ReST, thus my question.

Comments and suggestions are welcome.

I have a similar situation and found the answer to be in the model
rather than the RESTful api. Specifically, I allow the user to create
the record with the same ‘natural key’ and then use an observer to
determine if the natural key has already been used. If so, the
observer deals with whatever is necessary to set the effectivity dates
of the new object and the superceded one.

“Expire” is really no different than update, allowing the user to set
the expiration date. In our application, the user would be able to
modify this along with the other attributes in their admin interface.
You might conceive of ‘expire’ like a very specialized ‘edit’, though,
and give it a RESTful url as you’re suggesting. I would restrict that
method to presenting the very specific UI and letting the existing
#update take care of persisting the change.

On May 5, 12:46 pm, James B. [email protected]

AndyV wrote:

I have a similar situation and found the answer to be in the model
rather than the RESTful api. Specifically, I allow the user to create
the record with the same ‘natural key’ and then use an observer to
determine if the natural key has already been used. If so, the
observer deals with whatever is necessary to set the effectivity dates
of the new object and the superceded one.

Thank you. I had not considered that route (pardon the pun). I will
look into observers.