API：我们应该与数组参数一起使用哪个动词

Question

例如，我们需要一个 API 方法，它获取数组作为输入（设备 id 的数组）并返回这些设备的列表（关于每个设备的完整信息）。

所以，GET 方法的所有属性都有，但是在 url 中传递它是个坏主意（数组可以很大），所以最好在 body 中传递它：

    [HttpGet("api/deviceNames")]
    [ProducesResponseType(typeof(List<DeviceInfo>), StatusCodes.Status200OK)]
    public IActionResult GetDeviceNamesByIds([FromBody]List<string> deviceIds)
    {
        var d = _deviceService.GetDevicesByIds(deviceIds);

        return Ok(d);
    }

它工作正常。但是许多作者不建议将 body 用于 GET 方法，例如https://groups.yahoo.com/neo/groups/rest-discuss/conversations/messages/9962?guccounter=1

是的。换句话说，任何 HTTP 请求消息都允许包含一个 消息体，因此必须考虑到这一点来解析消息。服务器 但是，GET 的语义受到限制，因此主体（如果有） 对请求没有语义意义。解析的要求 与方法语义的要求是分开的。

所以，是的，您可以使用 GET 发送正文，但不，它对 这样做。

这是 HTTP/1.1 分层设计的一部分，将会变得清晰 再次对规范进行分区（正在进行中）。

....罗伊

但是，从另一边：

更新 被称为“HTTP/1.1 规范”的 RFC2616 现已过时。在 2014 年，它被 RFC 7230-7237 取代。引用“消息正文应该 处理请求时被忽略”已被删除。现在只是 “请求消息框架独立于方法语义，即使 该方法没有定义消息正文的任何​​用途”第二个引用 “GET 方法意味着检索任何信息……被识别 由 Request-URI" 被删除。-来自评论

Answer 1

RFC 7231 没有改变语义

GET 请求消息中的有效负载没有定义的语义；在 GET 请求上发送有效负载正文可能会导致某些现有实现拒绝该请求。

它不能正常工作 - 不是真的。问题是 HTTP 的缓存语义没有考虑请求体；通用组件将假定服务器尊重标准化语义，因此不会在请求的消息体中挖掘以查看请求数组是否与之前缓存的任何表示匹配。

这反过来意味着，为了防止兼容组件出现问题，您将不得不禁用资源缓存。

由于缓存是REST architectural style 中的一个重要约束，这显然是朝错误方向迈出的一步。

如果您必须使用有效负载，那么您可能应该查看POST，而不是GET。另请参阅：SOAP、GraphQL。

但是 POST 根本不是幂等的

没错。需要做出权衡。