我将数据存储在DynamoDB中作为Map属性类型，并实现一个宁静的PATCH端点来修改该数据（RFC 6902）。
在我的验证例程中，在将补丁转换为更新表达式并将其发送到DynamoDB之前，我目前尚未确定Map是否存在。
这意味着如果尚未在DynamoDB中设置Map，则更新将失败（ValidationException，因为文档路径不存在）。
我的问题：依靠DynamoDB以这种方式拒绝更新是否合适/可接受/可以，或者我应该获得该项目的副本并拒绝我自己的验证例程中的补丁吗？
我无法想到一个不允许DynamoDB拒绝补丁的原因（并且它为我节省了一个GET调用），但这让我有点紧张依赖于这样的第三方验证（虽然我们现在在访问AWS时指定了API版本，但理论上这应该始终有效...）
答案 0 :(得分：0)
这似乎是一个非常主观的问题，但我个人认为通过添加一个额外的DynamoDB往返来看不到做自己验证的好处，当我看到它时，可能发生的最坏情况是更新继DynamoDB之后。这与处理将成功作为权威的本地数据库更新没有什么不同。
如果您担心长期向后兼容性（即DynamoDB API合同从您下面改变），那么希望您已经编写了一些定期运行的功能/集成测试，特别是在您更新软件依赖项时。