How your service handles requests is completely up to you. You could basically create new resources on receiving GET
requests or delete things using OPTION
, though I highly recommend to not do so as this does not adhere to the backing protocol (HTTP in this specific case) and thus violates a basic REST constraints. Note further that a RESTful service should always adhere to and respect the supported protocols.
According to RFC 7231, one of the major differences between GET
and DELETE
is, that the latter one removes an association from a given resource and its functionality and also that the returned response is not cachable. This may or may not remove the data physically, the effect on consecutive DELETE
or GET
operations is, however, that the deleted resource should not be obtainable further. A consecutive DELETE
request is issued to the server regardless of any previous request. If the resource was deleted before, the service should notify the client with a propper 404 Not Found
error response if no new resource was created in between two delete operations on the same resource.
GET
responses, on the other side, are cachable and thus may save work on the server by returning the result from a previous request directly from the (proxied) cache rather then issuing the request to the server. This can be fine-grained with propper cache-header settings.