我已经实现了/ GET HTTP端点以提供搜索功能。用户发送查询参数中的搜索词,并接收包含所有搜索结果的JSON响应。
现在我必须添加一个新功能,即保存搜索。这意味着用户可以发送相同的搜索参数,还可以发送布尔参数,例如 save = true 。在这种情况下,我必须将搜索词保存在数据库中以备将来使用。但是,此参数不是必需的。
我对以下几点感到困惑:
执行此操作的标准/可接受方式是什么?
答案 0 :(得分:0)
据我了解您的问题,您尝试存储搜索请求,并通过存储搜索请求来一次性检索响应?
通常使用GET
来检索资源的状态,尽管此方法定义为safe
,如果为调用的资源创建了某些状态,则不应使用它,因为它将持久化搜索查询是。 RFC 7231进一步指出:
GET请求消息中的有效负载没有定义的语义;在GET请求上发送有效内容正文可能会导致某些现有实现拒绝该请求。
因此,我将避免使用选项#1或#2,因为这可能会破坏某些客户端的互操作性。
另一方面, POST
在RFC 7231中定义为
POST方法要求目标资源根据资源自身的特定语义来处理请求中包含的表示形式。
因此,应在其他HTTP操作不适合的所有情况下使用它。 HTTP规范进一步定义了创建新资源201 Created
的HTTP状态代码应返回,其中包括名为Location
的HTTP响应标头,其中包含所创建资源的URI。以后可以使用该URI检索其状态(即执行的搜索结果)。
从客户端的角度来看,您基本上是在服务器上存储一些查询定义,而不管服务器实际在何处或如何持久存储它。您要做的只是检索一个以后可以调用的句柄。这不会阻止服务器在响应有效负载内返回当前搜索结果。这就是我要做的。
建议步骤:
201 Created
和标题为Location
的标头返回指向存储查询的URI的响应,并将查询结果添加到响应有效负载之内客户端稍后可以使用返回的URI检索资源的当前状态,服务器可以将其解释为:执行针对该URI存储的查询并返回搜索结果。
REST体系结构未定义URI的外观。您可以根据查询generate生成UUID或生成哈希值。后一种方法的好处是,多个相同的查询不会导致创建其他查询,而会导致此类查询的重用。在这种情况下,应重定向到现有查询资源,以告知客户端他的查询已存在,这还会告知客户端该查询资源的实际URI。