I have an Application which requires data from Service2, which will return the same answer for a given request, forever, unless its backing database is updated. The database is
Consider using DELETE
instead of POST
and for the url:
/application/cache/
In REST, both PUT
and DELETE
are considered to be indempotent actions. That is, they can be repeated multiple times with the same resulting resource state. In this case, your cache is the resource and multiple DELETE
's will result in the same state, a cleared cache.
You could consider adding a descriptor to your url to clarify that you are clearing the contents of your cache and not deleting the cache object itself. Something like
/application/cache/contents
perhaps, but that is up to you. Going that route could also potentially let you selectively delete from your cache if necessary.
This might not answer your question directly but you may also want to look into HTTP ETags, which are well suited for caching in RESTful designs.
The idea would be that Application would GET a resource from Service2, which would return the resource along with a ETag header (it could be a last modified timestamp or a hash). Application would then cache that resource along with the ETag.
When Application needs to work with the resource again, it can send a HTTP GET to Service2 with the ETag header it has in cache.
This approach works well if you don't mind the HTTP GET to see if the resource changed and if it's easy to Service2 can determine whether the resource has changed (without having to load it).
The advantage is that Service2 doesn't have to invalidate the cache of it clients (Application), which might not be a very good practice (and could be hard to do if you have a lot of clients).