对于我的REST API设计，我允许使用If-Match条件标头修改(PUT, DELETE)资源以避免丢失更新问题。这与下面描述的内容类似:https://www.kennethlange.com/avoid-data-corruption-in-your-rest-api-with-etags/
然而，我知道有4个条件头(If-Match, If-None-Match, If-Modified-Since和If-Unmodified-Since)。是否可以忽略或禁止If-Modified*和If-UnModified报头?这是标准吗?
我认为ETags将是检查记录是否更新的更可靠的措施。在其他条件标头中使用datetime是不可靠的，我认为不需要。
那么只使用If-Match和If-None-Match头是可以的吗?如果是这样，我是直接忽略其他报头，还是返回400个坏请求?
那么只使用If-Match和If-None-Match头是可以的吗?如果是这样，我是直接忽略其他报头，还是返回400个坏请求?
我相信答案可以在RFC 7230中找到:
接收方必须根据本规范(包括本规范的扩展)为其定义的语义来解释接收到的协议元素，除非接收方(通过经验或配置)确定发送方错误地实现了这些语义所隐含的内容。
我对标准的理解是你可以忽略扩展，但是我没有看到任何文本允许你考虑在HTTP文档集中定义的头是扩展。
如果实际情况是某些客户发送给你一个If- unmodified - since标头，而你的实现忽略了它，结果发生了Big Expensive Mess，你将不会对你的律师的建议感到高兴。