AI生成的图像
鲁棒性原则：对自己要保守，对外部要宽容。
虽然这个原则最初是在传输控制协议（TCP）创建时定义的，但它在应用于现代API时在现代API中仍然很有用。
🔨 解读稳健性原则的解析：这个原则的核心在于，我们应该专注于按照规格办事，只发送符合规格说明的请求。
在实际操作中，这意味着要避免依赖那些未被记录的行为，特别是即使这些行为可能很常见。作为用户，我们应该严格要求自己不依赖这些未记录的行为。
作为服务器来说，我们需要允许客户端发送超出规定的消息。只要意图明确且没有恶意，就让它们通过。
💻 使用现代API：这条原则在现代的 JSON 基础 API 中非常实用。
作为一台服务器，允许用户发送超出API合同规定的数据（假设这些数据不是恶意的）非常重要。
例如，如果你的 API 调用期望收到一个包含五个键的 JSON，但实际收到的是包含六个键的 JSON，你应该怎么办呢？
如果你的 API 只接收了三个键，会怎样？
📨 收到可不代表就处理了，明白吗？作为服务器端，允许用户发送超出合同范围的数据可增强该系统的健壮性并简化更新。
随着系统的演变，多个团队并行工作是很常见的。
如果服务器无法处理更多的数据，在添加新数据字段时，客户端和服务器之间的协调就会变得必要。
不过，如果服务器允许带额外数据的请求，用户可以自行更新，只要新增数据而不修改现有字段即可。
关键是要区分接受和处理的不同之处。
JSON这样的结构有个好处是，可以加入额外的数据，但不需要处理这些额外的数据，即使它们存在也无需理会。
你可以忽略这个，然后按规矩处理请求。
🛑 必填字段和默认字段:我经常看到的一个常见错误，特别是在处理后端微服务时，总是希望每个请求都包含完整的JSON数据。
如果我们认为该原则对API输入内容具有灵活性，则适用于接收超出或少于预期的数据。
在定义API合约的过程中，明确必填字段、条件字段和默认设置是十分重要的。
这样一来，即使用户只发送了数据的一部分，只要所需的和条件性必需的字段存在且有效，也可以进行处理。
这不仅从用户角度看是个很好的特性（他们只需关心对他们真正重要的东西），而且在给 API 添加新字段时，也有助于我们。
在向 API 添加新字段时，你是否希望强制所有用户更新并使用这个新字段？还是可以设置强默认设置，让真正关心这个字段的用户自行更新？
根据我的经验，如果不和用户同步系统更新，更新次数越多效果越好。
🔒 实际上，灵活 ≠ 意味着不安全:虽然我主张灵活处理并接受意外的数据，不过这并不表示你可以忽略安全。
尽管允许额外的数据很重要，但也存在一个限制。
避免接收任意大小的负载；应限制负载的大小和数据类型，以防止拒绝服务攻击。
确保验证处理的数据，使其符合你期望的类型。日期应为日期格式，数字应为数值并符合某种预期模式。
接受额外数据的灵活性并不意味着你需要允许处理不符合预期的数据。
确保所有必需的字段都存在。如果你允许用户发送部分数据并用默认值填充，那么确保每个请求都包含所有必需的字段尤为重要。
严格要求填写必填字段比宽松规则更好，在宽松规则下所有字段都会被包含。
将这个原则应用到内部和外部API上：许多人擅长将这些原则应用于外部API，但在内部实施这些原则时却做得非常糟糕。
不要落入认为内部API和微服务之间的API就不会遇到同样问题的陷阱。
按照这样的做法和原则，可以让管理内部 API 更加简单，也更容易让用户使用和保养。