7

For example, if I call GET to get an item, delete it with DELETE and GET it again, how should the second GET work?

I mean, by correctly following REST principles, what is the right approach in doing this since GET can be cached and all? What's the approach for handling stale data in REST?

JohnDoDo
  • 4,720
  • 8
  • 31
  • 47
  • If you just deleted the item why would you be trying to "get" it again? It won't exist. Maybe I'm missing something or the question wasn't clear. – Brent Pabst May 24 '12 at 13:05
  • @Brent Pabst:Consider for example links in a UI application where delete happens in a popup but the GET link is in the opener page and does not get updated, or transferred by mail and user inserts them into the browser address bar directly in between the delete etc. This is subject to cache! The idea is, if the item isn't there anymore how should the GET work. Disable ALL cache? Is it acceptable to have some cache? What's the REST approach to all of this? – JohnDoDo May 24 '12 at 13:18
  • 3
    The second GET would naturally return the HTTP code `404 Not Found`. Caching is quite another matter for which I shall provide the marvellously opaque answer: "it depends". But if there *is* a second GET, it seems rather obvious that it would be producing a 404? – Chris Morgan May 24 '12 at 13:22
  • 1
    Chris' comment should be an answer for the question, its definitely a 404, caching be damned. A DELETE should in fact purge the key for that resource from the cache anyway. – cfeduke May 24 '12 at 13:33

2 Answers2

4

First of all, the behavior depends on what the DELETE call returned as its response code.

If DELETE returns 200 - OK or 204 - No Content then the client should get 404 - Not Found on its next call to GET. That's because 202 and 204 mean that the resource was deleted immediately.

However if DELETE returns 202 - Accepted, there's a chance that the client will be able to successfully GET the resource for some time afterwards. That's because 202 means that the resource has been marked for deletion, but not necessarily cleaned up immediately.

Secondly, if there's a cache involved, the behavior should be built to be consistent with what would happen if there was no cache present. A successful DELETE should always lead to a removal both from the true origin of the data in addition to any cached copies.

Brian Kelly
  • 19,067
  • 4
  • 53
  • 55
0

As originally stated a GET following a DELETE should produce a HTTP 404 error irrespective of caching that may be in place. The logic code should be smart enough to remove the record from the persistent store as well as the in-memory store or cache. In addition the UI should be able to handle the result of the 404 with whatever flow or process you deem appropriate.

Brent Pabst
  • 1,156
  • 1
  • 15
  • 37