问API REST，当GET limit冲突语义时

EN

REST只是我们日常使用的Web的泛化。基本上，您可以在REST环境中应用与Web相同的技术。也就是说，如果有太多选项可用，或者自由文本输入可以轻松超过2k个字符，您可以使用POST执行调用并通过有效负载发送数据，或者重新设计您的方法。前一种方法缺乏对safe和idempotent等有价值属性的支持，也可能会完全避免缓存。

另一种方法是对客户端可以作为自己的资源发送的选择进行建模。这允许对某些配置进行“命名”和重用，并通过简单的GET请求进行调用。在HTML中，客户端可以请求所有可用的配置并选择适合其需要的配置，或者向服务器请求一个表单页面来输入选择并通过POST将其发送到服务器。此配置稍后将出现在将来的客户端请求中，以获取可用配置。

指向特定资源的URI的实际结构通常对客户端并不重要，因为应该使用有意义的(链接关系)名称来确定要调用哪个URI。这样的资源可以很容易地通过自动提供上述属性的GET调用。这里的关键部分是找到一个对客户端有意义的命名方案，这样客户端就能理解这个URI的实际用途。

此外，将表单转换为REST架构可能不是最简单的事情。在HTML中，规范已经包含了表单和选择以及链接的语义。你可以重用这个特定的特性，或者想出你自己的媒体类型，比如application/vnd.form-hal+json，它可能是HAL-JSON的一个扩展，它已经定义了链接的结构。具体地，该媒体类型告诉这样的有效载荷的接收者，在这样的表示中接收的数据旨在以表单或表示表单数据的形式呈现，并且因此可以包含用户输入以显示或存储。

因此，找不到任何当前查询配置匹配的客户端可能会询问服务器如何创建新配置。服务器将向客户端通知上述表示的有效负载，如果客户端理解上述表示，则将导致客户端以有意义的方式向其用户显示数据，或者甚至允许客户端采用该表示并自己填充所需的信息，并通过POST将其发送回服务器，以便创建新的查询配置。然后，对可用配置的进一步请求也应列出新配置。

正如您希望看到的，Web中使用的相同技术也可以应用于REST。由于服务器教导客户端如何发送请求，且客户端不需要关于服务任何先验信息，因此这种方法具有相当好的伸缩性且在实践中是相当健壮的。这项技术还解释了菲尔丁在他的一个blog posts中所要求的

REST API 应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或者定义现有标准媒体类型的扩展关系名称和/或启用超文本的标记。用于描述在感兴趣的URI上使用什么方法的任何工作都应该完全在媒体类型的处理规则的范围内定义(在大多数情况下，已经由现有的媒体类型定义)。这里的失败意味着带外信息正在驱动交互，而不是超文本。