rest和rest ful

在以前的博客文章中，我介绍了一些实现REST体系结构的想法和技巧。 在这篇文章中，我将介绍更多的想法和技巧。

快取

• 缓存是原始论文的很大一部分。 见5.1.4节
• 策略包括验证（ 客户端检查它是否具有最新版本 ）和过期（ 客户端认为它具有最新版本直到指定时间 ）。
• 到期日：
  • Expires标头告诉客户端资源何时到期。
• • 缓存控制
• 验证方式
  • Etag –资源的唯一版本。

控制器API

• 当某些东西完全适合CRUD操作时，请考虑使用Controller API

处理日期

• 使用ISO-8601作为日期-更好地进行自然排序，处理时区，语言环境中的语言以及大多数编程语言的支持
• 接受任何时区，因为世界上任何人都可以调用您的API
• 存储在UTC中 ，而不是服务器所在的时区中。 持续时不应有偏移。
• 返回UTC。 允许客户根据需要调整其时区
• 如果您不需要时间，请不要使用。 如果仅日期就足够，则仅保留日期。 这意味着时区复杂性将消失。

头

• HEAD操作应返回响应头

标头

• 始终返回有用的标题。 考虑：
  • 内容类型

超媒体（优势）

• 减少耦合
• 链接的格式一致=>更干净的客户端代码
• 开发人员的生产力：API更易于浏览
• 更轻松地以更精细的方式介绍服务
• 代码更易于调试-消息始终具有通过自我链接创建消息的URL

超媒体（选择）

• HAL –减少地址耦合
• SIREN –减少地址和动作的耦合
• Collection + JSON （CJ）–减少地址，动作和对象的耦合

幂等

• 可以多次调用并返回相同结果
• OPTIONS，GET，HEAD，PUT和DELETE都是幂等的

长时间运行的请求

• 某些操作需要很长时间。 在这种情况下，请考虑返回位置字段设置为URL的202，客户端可以轮询该URL以检查操作进度。

不允许的方法

• 如果API仅支持GET，则对于任何PUT，POST，DELETE等都应返回405

必须忽略原则

• 客户端应该忽略他们不感​​兴趣的数据。这使得API向后兼容变得更加容易。 如果API返回了额外的数据，而某些客户端并不期望它们，他们将忽略它。

不能接受的

• 当资源不支持特定的媒体类型时，当无法提供所请求的媒体类型时，必须返回406（ 参见Masse，规则：406（“不可接受”））

选件

• 选项应返回资源上可用的操作

部分更新

• 使用PATCH处理部分更新

询问

• URI的查询组件应用于过滤集合

资源创造

• 成功创建资源后，应返回201
• 位置标头应指示获取资源的URL。

安全

• 如果操作不修改资源，则被认为是安全的
• 选项，GET和HEAD是安全的

自我链接

• 响应正文应始终包含一个自我链接-用于返回资源的URL。

单数还是复数？

• 对于单文档类型资源，请使用单数-当只能有一个时。 例如：/ humans / 12343343 / head
• 否则复数

翻译自: https://www.javacodegeeks.com/2018/05/and-some-more-rest-tips.html

rest和rest ful