Question

当前，我要问我在我的rest api上使用的当前HTTP方法是否是正确的方法，我的端点需要大量数据来“匹配”查询，所以我做了一个POST端点，用户可以在其中发送带有参数的json，例如：

{
    "product_id": 1
    "partner": 99,
    "category": [{
        "id": 8,
        "subcategories": [
            {"id": "x"}, {"id": "y"}
        ]
    }]
    "brands": ["apple", "samsung"]
}

请注意，brands和category是一个列表。

阅读我发现的mozzila page about http methods：

POST方法用于将实体提交给指定的资源，通常会导致服务器状态改变或副作用。

我的POST端点对我的服务器/数据库没有任何影响，因此理论上我使用的是错误的（？），但是如果我使用GET的请求，我该如何做得更多“可读”，我该如何管理这种方法的列表？

Answer 1

当我需要将大量数据传递到单个端点时应该使用哪种HTTP方法？

来自RFC 7230

在实践中发现了对请求行长度的各种临时限制。建议所有HTTP发送者和接收者至少支持8000个八位位组的请求行长度。

这有效地限制了您可以编码到target-uri中的信息量。如果您必须支持不遵循此建议的客户或中介机构，那么实践中的限制可能还会更低。

如果服务器需要信息，并且您无法将其编码为URI，则基本上只能将其编码为消息正文；反过来，这意味着GET-不管怎么说，否则语义可能适合您的设置-都无法显示：

GET请求消息中的有效负载没有定义的语义

就是这样-您陷入POST的困境，并且失去了safe语义，idempotent语义和缓存。

要考虑的一种可能替代方法是创建一个资源，客户端可以稍后获取该资源以检索匹配的当前表示形式。对于第一个临时查询来说，这并没有使事情变得更好，但是对于重复查询，它确实为您提供了更好的语义。

例如，您可以将消息正文复制到文档存储中，并将文档存储的密钥（例如文档的哈希）编码为URI，以供客户端在后续GET中使用。

对于JSON文档的样板很大而变体的编码较小的情况，则可以考虑使用一系列资源将变体编码为URI。实际上，该变体是从URI中提取的，并应用于服务器的模板副本，然后使用完全重构的JSON文档来实现...

Answer 2

您仍然应该使用POST。使用Get，您只能通过URL参数或HTTP标头“上传”数据。两者都不适合像您这样的结构化数据。即使服务器上没有“更改”，也要使用POST。

当我需要将大量数据传递到单个端点时应该使用哪种HTTP方法？

2 个答案: