首页 > 解决方案 > API REST,当 GET 限制与语义冲突时

问题描述

构建 API REST 时,应使用 GET 请求来查询数据。是教科书。但是 GET 仅限于低千字符范围,而 POST 则没有这种限制(通常为几 MB)。

那么,您如何处理超过 GET 限制的请求(假设您有一个 API,并且您发送了一个邮政编码数组,以返回一个名称数组)?

在这种特殊情况下,我使用 POST,因为数组高于 GET 限制。它有效,但有些人会认为这是可耻的。
所以我想知道处理此类问题的规则是什么。
出于明显的性能原因,请求 n 次唯一的邮政编码不是一种选择。

标签: restapihttp

解决方案


REST 只是我们日常使用的 Web 的概括。您基本上可以在 REST 环境中应用与 Web 相同的技术。即,如果有大量可用选项或自由文本输入很容易超过 2k 个字符,您可以使用 POST 执行调用并通过有效负载发送数据或重新设计您的方法。前一种方法缺乏对有价值的属性的支持,例如safeandidempotent并且可能根本避免缓存。

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

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

此外,将表单转换为 REST 架构可能不是最简单的事情。在 HTML 中,规范已经包含了表单和选项以及链接的语义。您可以重用该特定功能或提出自己的媒体类型,即application/vnd.form-hal+json可能是 HAL-JSON 的扩展,它已经定义了链接的结构。这种媒体类型特别告诉这种有效载荷的接收者,以这种表示形式接收的数据旨在以表格形式呈现或表示表格数据,因此可能包含要显示或存储的用户输入。

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

正如您所希望看到的,Web 中使用的相同技术也可以应用于 REST。这种方法可以很好地扩展,并且在实践中非常健壮,因为服务器会教客户端如何发送请求,而客户端不需要任何关于服务的先验信息。这种技术还解释了菲尔丁在他的一篇博文中所要求的:

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


推荐阅读