HTTP条件请求

如何使用检查订单状态的自定义条件实现条件请求？

示例：

用户将发送带有标题的GET/api/order"；x-if-ready-for-payment"：是的。
- 如果订单已准备好付款，响应将是订单和状态代码200
- 如果订单还没有准备好付款，则响应将是带有状态代码412的错误消息

这是正确的方式吗？还是我完全错过了条件要求的要点？

条件请求基本上(但请在此处阅读更多内容(旨在：

另请参阅RFC 7232，超文本传输协议(HTTP/1.1(：条件请求：

条件GET请求是HTTP最有效的机制缓存更新[RFC7234]。条件也可以应用于状态改变方法，例如PUT和DELETE，以防止；迷路的"更新"；问题：一个客户端意外覆盖了另一个一直在并行操作的客户端。

它不适用于您的自定义业务逻辑。您的x-if-ready-for-payment听起来像是需要发明几十个只适用于单个或少数请求的新标头。

确定你真正想解决的问题，然后找到不同的解决方案。

这是正确的方式吗？还是我完全错过了条件需求的要点？

CodeCaster有正确的想法；我想尝试一种更广泛的方法

HTTP是一种应用程序协议，其应用程序域是通过网络传输文档--Jim Webber，2011

所有元数据——方法标记、状态代码、标头——都属于"；文件转让"；领域

REST的一个关键约束是统一接口；web上的所有资源都以相同的方式理解请求消息。

GET /api/order

应该具有与相同的语义

GET /cute/kitten.jpg

由于语义是标准化的，并且实现遵循这些标准，我们最终得到了一堆通用工具(如网络浏览器(，这些工具可以以许多有趣的方式使用——你可以使用在youtube上观看视频或在StackOverflow上提问的同一浏览器进行购物和银行业务，等等；只是起作用"；。

引入特定于特定服务器或特定资源的头，会与当前情况背道而驰——您可以编写一个也理解x-if-ready-for-payment的定制客户端，但现在我们已经耦合到一个定制客户端，而不能使用任何HTTP标准感知文档读取器。

当然，新的头可以标准化——我们有向IANA注册表添加新HTTP头的协议，但如果你的头不是通用的，那么在注册后实现采用将是一个额外的头痛问题。

如果客户询问订单状态，那么您可能应该做的是将该状态包括在资源的表示中，例如

GET /api/order

200 OK
Content-Type: text/plain
x-if-ready-for-payment=true

如果客户端试图更改订单状态，则使用消息语义来指示我们正在尝试更改服务器的资源副本，例如：

POST /api/order
Content-Type: text/plain
x-if-ready-for-payment=true

(在我的例子中，内容类型只是为了减少歧义，它可以很容易地是application/x-www-form-urlencoded、application/json、application/prs.djoloho+json或其他……(

相关内容