# ReSTfull depreciation of row entries **URL:** \ **Category:** Rails\ **Created:** [May 5, 2008, 6:46pm UTC](https://www.ruby-forum.com/t/restfull-depreciation-of-row-entries/136702 "2008-05-05T18:46:41Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![byrnejb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/d2c977/32.png) [@byrnejb](https://www.ruby-forum.com/u/byrnejb)\ **Post date:** [May 5, 2008, 6:46pm UTC](https://www.ruby-forum.com/t/restfull-depreciation-of-row-entries/136702/1 "2008-05-05T18:46:41Z")
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. ---
**Author:** ![byrnejb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/d2c977/32.png) [@byrnejb](https://www.ruby-forum.com/u/byrnejb)\ **Post date:** [May 5, 2008, 9:53pm UTC](https://www.ruby-forum.com/t/restfull-depreciation-of-row-entries/136702/2 "2008-05-05T21:53:30Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![byrnejb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/d2c977/32.png) [@byrnejb](https://www.ruby-forum.com/u/byrnejb)\ **Post date:** [May 6, 2008, 3:12am UTC](https://www.ruby-forum.com/t/restfull-depreciation-of-row-entries/136702/3 "2008-05-06T03:12:31Z")
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.