如何使用长查询参数列表设计RESTful查询API?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (255)

所以,我需要设计一个RESTful查询API,它基于几个过滤器返回一组对象。通常的HTTP方法是GET。唯一的问题是,它可以有至少十几个过滤器,并且如果我们将它们全部作为查询参数传递,URL可能会变得很长(足够长以被防火墙阻止)。

减少参数数量不是一种选择。

我能想到的另一种方法是在URI上使用POST方法,并将过滤器作为POST主体的一部分发送。这是反对RESTfull(进行POST调用查询数据)。

任何人有更好的设计建议?

提问于
用户回答回答于

请记住,使用REST API,这都是视图问题。

REST API中的两个关键概念是端点和资源(实体)。宽松地说,端点通过GET返回资源或通过POST和PUT等(或上述的组合)接受资源。

可以接受的是,通过POST,您发送的数据可能会或可能不会导致创建新资源及其关联的终端,而这些终端很可能不会在POST网址下“活”。换句话说,当你POST时你发送数据的地方进行处理。POST端点不是通常可以找到资源的位置。

引用RFC 2616(省略不相关的部分,并强调相关部分):

9.5 POST POST方法用于请求源服务器接受请求中包含的实体作为Request-Line中Request-URI标识的资源的新下属。POST旨在允许统一的方法来涵盖以下功能:

  • ...
  • 向数据处理过程提供一组数据,例如提交表单的结果;
  • ...

... POST方法执行的操作可能不会导致可以通过URI标识的资源。在这种情况下,200(OK)或204(无内容)是适当的响应状态,具体取决于响应是否包含描述结果的实体。 如果在原始服务器上创建了一个资源,那么响应应该是201(创建)...

我们已经习惯了代表'事物'或'数据'的端点和资源,无论是域,用户,消息还是书籍。但是,端点也可以公开不同的资源 - 例如搜索结果。

考虑下面的例子:

GET    /books?author=AUTHOR
POST   /books
PUT    /books/ID
DELETE /books/ID

这是一个典型的REST CRUD。但是,如果我们添加:

POST /books/search

    {
        "keywords": "...",
        "yearRange": {"from": 1945, "to": 2003},
        "genre": "..."
    }

这个端点没有任何不可靠的地方。它以请求主体的形式接受数据(实体)。该数据是搜索标准 - 与其他任何DTO一样。该端点响应请求产生资源(实体):搜索结果。搜索结果资源是一个临时的资源,立即向客户端提供,没有重定向,也没有公开其他规范网址。

它仍然是REST,除了实体不是书籍 - 请求实体是书籍搜索条件,而响应实体是书籍搜索结果。

用户回答回答于

许多人已经接受这样一种做法:具有太长或太复杂查询字符串的GET(例如,查询字符串不能轻松处理嵌套数据)可以作为POST发送,而用体内表示的复杂/长数据的请求。

在HTTP规范中查找POST规范。它非常广泛。(如果你想通过REST中的漏洞航行战舰......请使用POST。)

你失去了GET语义的一些好处,比如自动重试,因为GET是幂等的,但是如果你能忍受,那么接受POST处理真正长或复杂的查询可能会更容易。

扫码关注云+社区

领取腾讯云代金券