如何将此请求表示为 RESTful API？

Posted 2023-03-31

【中文标题】如何将此请求表示为 RESTful API？

【英文标题】：How to express this request as a RESTful API?

【发布时间】：2015-12-28 18:43:50

【问题描述】：

我被要求编写一个基于 HTTP 的小型服务，该服务将接受如下所示的请求：

[
    name: 'James Smith', address: '10 Lake Drive' 
    name: 'Jones', phone_number: '999-123-4567' 
    name: 'Mr. Lucas', address: 'Detroit, MI' 
]

（但请求数量较多）并尝试确定每个帐户是否存在一个帐户，返回如下所示的数据：

[
    name: 'James Smith', address: '10 Lake Drive', account='123ABC' 
    name: 'Jones', phone_number: '999-123-4567', account='Not Found' 
    name: 'Mr. Lucas', address: 'Detroit, MI', account='654CBA' 
]

此服务的客户端（至少，我所知道的第一个客户端）将同步使用此数据——它无法继续，直到它从服务接收回帐号。 （将规格请求项目与帐户匹配的实际处理并不重要。）

我被要求为此服务提供 RESTful API。我可以看到将其封装在 RESTful API 中的唯一方法是创建包含一个或多个查找请求的“LookupRequestDocument”的概念。客户端将POST this 发送到\LookupRequests\ 的URI，接收服务器为整个请求生成的URL，然后使用GET 轮询该URL，直到响应准备好。

这让我感觉不舒服，原因如下：

我创建了一个新概念（LookupRequestDocument“资源”），只是为了让 API 成为 RESTful 风格 - 在问题陈述中没有其他存在。 我已经将异步性引入了同步问题。

对我来说，POST 将数据发送到像 \DoMatches 这样的 URI 并在返回的文档中获得完整的结果似乎更自然。但这似乎不符合我的客户的 API 是 RESTful 的要求。

问题：我将问题封装到 RESTful API 中是否是解决此问题的“成为 RESTful”的最佳方式？我的\DoMatches 解决方案实际上是 RESTful 的，即使它不涉及我理解的资源？

【参考方案1】：

因此，您的 LookUpRequests 流程似乎不是 RESTful。它不是无状态事务，它需要在服务器上存储和处理帖子中的信息，然后在不同的请求中返回。

我会做 \DoMatches 但你真的“发布”任何你的“获取”信息吗？那么为什么这不是一个 GET 请求，其响应是答案/答案？

【讨论】：

我正在“发布”一个请求。我也可以将其视为GET，但我必须将所有搜索编码到参数中，不是吗？

【参考方案2】：

两者都不是 RESTful。这就是 RPC，纯粹而简单。

RESTful 方法将每个帐户视为一个资源，由 URI 标识，并在单个请求中检查每个帐户。

如果您不想有多个这样的请求，您可以使用更高级别的界面作为解决方法，您可以在其中通过 POST 提交 URI 列表（mimetype text/uri-list）并获得207 Multi-Status具有相同的响应。

【讨论】：

除了我不知道我所追求的资源 URI 吗？是否会针对集合表示为 GET，并期望返回单个 URI？

可能是通过使用负载中的值作为查询字符串参数来过滤集合。