我们正在设计HTTP REST API。 该API通过HTTP GET方法公开某种类型的资源。在内部，应用程序从数据库中检索数据，进行一些处理，然后在对HTTP GET的回复中显示结果。
我们要添加到此架构中的是一些针对数据库损坏的弹性。由于存储在DB中的数据的格式，我们有两种可能性：要么可以在检索后对数据进行解码，要么可以不对数据进行解码。我们旨在标记无法解码为“损坏”记录的记录。因此，该应用程序将只能过滤损坏的记录，将其列出...
我们面临的问题是，因为只有GET方法才能解码DB的内容以将其显示给客户端调用，所以只有GET方法才能拥有损坏记录的信息。但是由于GET需要安全，因此即使HTTP协议明确指出GET绝对不能这样做，我们是否能够允许GET修改资源的状态以防万一损坏？
如果不是这样，并且即使在这种限制情况下也要避免使用GET修改任何资源，我们将被迫记录损坏的记录以对其进行手动操作，或者进行批处理来为我们做。两者都不是特别吸引人。
答案 0 :(得分：1)
从客户的角度来看，这很安全。您的服务器在内部执行的操作实际上并不重要（请参阅https://greenbytes.de/tech/webdav/rfc7231.html#safe.methods：“安全方法的此定义不会阻止实现包含可能有害的行为，并非完全只读的行为，或在执行操作时引起副作用的行为调用一种安全的方法，但是重要的是，客户端没有请求其他行为并且对此不承担任何责任，例如，大多数服务器在每次响应完成时都将请求信息附加到访问日志文件中，而无论这种方法，即使日志存储空间可能已满并使服务器崩溃也被认为是安全的。同样，通过选择Web上的广告发起的安全请求通常会产生向广告帐户收费的副作用。“）
答案 1 :(得分：0)
HTTP GET方法会永远不安全吗？
是的。这是Roy Fielding，addressing that question：
HTTP不会尝试要求GET的结果是安全的。该操作要求操作的语义是安全的，因此，如果发生任何导致财产损失的结果（钱，BTW，为了这个定义，它被视为财产。）
关键思想是，由于GET是安全的，因此缓存可以预取实际上可能不需要的资源，蜘蛛程序/索引器可以进行探索，等等。
因此您需要执行一些特定于实现的数据管理以提供服务的事实很好。