我习惯于(在Python和Java中(查看定义为{键：值}的字典/哈希映射
AWS 使用格式 { "Key" ： key， "Value" ： val }
这种方法从何而来？ 它增加了复杂性，从这种复杂性中获得好处吗？
编辑：一个例子是标签的格式：
Tags=[
{
'Key': 'string',
'Value': 'string'
},
]
一种可能性：AWS 倾向于对不同情况下的线路数据结构使用相同的格式，以保持一致性，通过减少可变性来降低整体系统复杂性。 这方面的明显例子是 S3 事件通知和Lambda@Edge触发器，其中事件数据结构(此处显示为{ ... }(不必要地包装在一个具有一个键的外部对象和一个具有一个成员的内部数组中{"Records": [{ ... }]}即使根据定义在这些情况下，Records数组永远不会具有更多或更少的内部对象。 他们这样做是为了保持一致性。
另一种可能的解释是：SDK 用于与服务通信的低级 API 使用 XML¹，其中这种结构更有意义。
在 EC2 API 参考DescribeTags操作中，下面是一个示例响应：
<tagSet>
<item>
<resourceId>ami-1a2b3c4d</resourceId>
<resourceType>image</resourceType>
<key>webserver</key>
<value/>
</item>
<item>
<resourceId>ami-1a2b3c4d</resourceId>
<resourceType>image</resourceType>
<key>stack</key>
<value>Production</value>
</item>
...
</tagSet>
它是一个具有多个属性的对象数组。 情况并非总是如此，但这让我们回到了上面的"一致性"论点。
诚然，使用起来通常非常尴尬，字典似乎更简单，但SDK似乎只是保留了在线上使用的基础数据格式，只需最少的转换，并且该格式是多年前在以XML为中心的世界中采用的。
另一种可能性：可以看出，这里也有多个键候选者，它们可以使用嵌套字典结构：
{
"image": {
"ami-1a2b3c4d": {
"webserver: "",
"stack": "production",
...
}
}
}
此结构不适合响应分页。 许多 API 操作返回有限的结果集和继续标记。
这种"改进的"嵌套结构也可以说更难扫描"key"等于"stack"的所有标签，因为您必须上下遍历树。
¹ XML...也有例外，而且在很大程度上没有记录的是，许多XML服务API秘密地支持JSON，其中一些甚至支持使用XML发送请求并通过使用HTTP请求标头来表示您的意图来接收JSON中的响应。但是在网络上的JSON交互的情况下，有相同的证据表明，它们似乎在服务端将XML转换为JSON，保留结构，或者对两种格式使用相同的本机结构，这对于使服务交互相同而不管序列化如何都是有意义的。
这种方法的一个好处是你不需要提前知道密钥，所以你可以更灵活/模块化，允许第三方添加键和值。