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

【问题标题】：How to express this request as a RESTful API?如何将此请求表示为 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 的，即使它不涉及我理解的资源？

【问题讨论】：

标签： api rest

【解决方案1】：

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

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

【讨论】：

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

【解决方案2】：

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

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

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

【讨论】：

除了我不知道我所追求的资源 URI 吗？是否会针对集合表示为 GET，并期望返回单个 URI？
可能是通过使用负载中的值作为查询字符串参数来过滤集合。