考虑在网络中应用REST原则。 我正在做一个关于REST的案例研究，我对Uniform接口有一些疑问。 我假设Uniform Interface只有一个单独的PROCESS而不是HTTP动词（例如get，post，put，delete，head，...）。传统的HTTP动词是否存在这种过程的潜在后果？
答案 0 :(得分：0)
传统的HTTP动词是否存在此类过程的潜在后果？
有一些。
一个考虑因素是安全性。在RFC-7231中，safe以这种方式定义。
如果请求方法的定义语义基本上是只读的，则被视为“安全”;即，由于将安全方法应用于目标资源，客户端不会请求，也不会期望源服务器上的任何状态更改。
因此，如果PROCESS是一个安全的动词，比如GET，那么你就可以使用只读网络的模拟。 HTTP规范还定义了HEAD和OPTIONS（优化读取）和TRACE（调试工具）;鉴于HTML是一种非常成功的超媒体格式而不包括对这些方法的支持，这表明它们对自己并不特别批评。
PROCESS的安全规范保留了REST的所有扩展优势。但它的效用是有限的 - 客户可以消费内容，但他们不能生成任何内容。
另一方面，如果PROCESS不安全，则无法再支持一堆用例。预取内容不再是一个选项，因为组件不能再认为调用PROCESS对服务器没有副作用。由于同样的原因，爬行不再是一种选择。
可能值得注意网络中方法的机制 - 它是超媒体格式，描述哪些方法适合哪些链接。因此，您可以通过在超媒体格式本身中定义对方法的限制来解决某些问题。这是将相同信息传递给任何可以使用相关媒体类型的组件的不同方式。
但至少有两个额外的考虑因素。首先，链接中的信息只能由知道媒体类型的组件来理解。在网络上，大多数组件都是媒体类型不可知的 - 缓存html看起来就像缓存json看起来像缓存jpeg。
其次，链接中的信息仅在出站方可用。 REST意味着无状态 - 处理请求所需的所有信息都包含在请求中。这意味着请求必须在其中包含处理通信故障所需的所有信息。
例如，http规范定义了idempotent。
如果使用该方法对服务器的多个相同请求的预期效果与单个此类请求的效果相同，则请求方法被视为“幂等”。
当intermediary components转发请求时，此属性对于{{3}}非常重要，并且不会收到服务器的响应。我们无法知道消息是丢失，还是只是缓慢，我们无法区分丢失的请求消息和丢失的响应消息。
如果请求包含信息是幂等的，那么中介就知道他们可以将消息重新发送到服务器，而不是将错误报告给客户端。
将此与http中的POST正确处理进行对比;由于POST请求上没有幂等标记，因此组件不知道重新发送消息会产生预期效果（这就是为什么Web浏览器通常会在尝试POST表单两次时显示警告的原因）。
将自己锁定在一个方法中可以让您做出选择;你想支持中介的错误恢复吗？或者您是否希望灵活地支持非幂等写入？