Question

我被要求编写一个基于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设置为\LookupRequests\的URI，接收服务器生成的整个请求的URL，然后使用GET轮询该URL，直到响应准备就绪。

由于以下原因，这让我觉得不舒服：

我创建了一个新概念（LookupRequestDocument“资源”），仅允许我使API RESTful - 它在问题陈述中没有其他存在。
我已经将异步性引入了同步问题。

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

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

Answer 1

所以看起来你的LookUpRequests进程不是RESTful。它不是无状态事务，它要求在服务器上存储和处理帖子中的信息，然后在不同的请求中返回。

我会做\ DoMatches，但你真的是＆＃34; POSTING＆＃34;任何你的＆＃34; GETTING＆＃34;信息对吗？那么，为什么这不是一个GET请求，响应是答案/答案？

Answer 2

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

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

如果您不希望有这样的多个请求，您可以使用更高级别的界面作为解决方法，通过POST提交URI列表（mimetype text / uri-list）并获取{ {1}}与等效的回复。

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

2 个答案: