Can HTTP GET method be ever unsafe?

Question

We are designing a HTTP REST API. This API exposes a certain type of resource via the HTTP GET method. Internally, the application retrieves the data from the databases, does some processing and then shows the results in the reply to the HTTP GET.

What we want to add to this schema is some resiliency against DB corruption. Because of the format of the data stored in the DB we have two possibilities: either the data can be decoded after retrieving or not. We aim to flag the records which can't be decoded as "corrupted" records. The application would, therefore, be able to filter corrupted records only, list them...

The issue we are facing is that because it is only the GET method decoding the content of the DB to show it to the client call, it is only the GET method who has the information of the corrupted record. But since GET needs to be safe, can we afford to allow GET to modify the status of a resource in case it is corrupted despite HTTP contract specifically saying GET should never do that?

If not, and in case we should avoid using GET to modify any resource even in this limit case, we would be forced to either log the corrupted records to manually act upon them or else make a batch run to do it for us. Neither of the two is particularly appealing.

Answer 1

Can HTTP GET method be ever unsafe?

Yes. Here's Roy Fielding, addressing that question:

HTTP does not attempt to require the results of a GET to be safe. What it does is require that the semantics of the operation be safe, and therefore it is a fault of the implementation, not the interface or the user of that interface, if anything happens as a result that causes loss of property (money, BTW, is considered property for the sake of this definition).

The key idea is that, because GET is safe, caches can pre-fetch resources that may not actually be needed, spiders/indexers can explore, and so on.

So the fact that you need to perform some implementation specific data management to provide the service is fine.

Answer 2

What's relevant is that it's safe from the client's point of view. What your server does internally really does not matter (see https://greenbytes.de/tech/webdav/rfc7231.html#safe.methods: "This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and crash the server. Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.")