REST风格的API设计。如果请求带有过滤器，您是否也应该返回该过滤器的值？

可以说客户端的GET请求/ items/color/{color}REST风格的API设计。如果请求带有过滤器，您是否也应该返回该过滤器的值？

当服务器返回具有所述颜色的对象数组时，每个item对象是否都有颜色属性？

客户端知道返回项目的颜色，因为他请求颜色，所以服务器是否应该尝试使响应大小更小或不响应？

编辑：人们可以更多地节省带宽部分？如果最好能够返回整个资源，答案可以包括为什么返回整个资源与节省带宽相比更好，而不是为什么应该返回整个资源。

来源

2016-11-07 Erndob

一般来说（至少这是REST的理念，据我所知），请求的结果应始终为完整资源。如果该项目包含成员color，则没有理由在结果中禁止该成员。这与REST资源的概念相矛盾。资源不会更改其属性。

抑制成员不仅会意外，甚至可能在客户真正期望该成员时破坏客户。

让我们假设客户端有功能来解析您的REST调用的结果而无需过滤器。所有字段将被返回，客户端将解析所有字段。现在客户端请求完全相同的资源（item），但突然间字段不同 - 从上面解析结果的代码不能被重用。

另外，当你考虑它时，可能会有更多的工作压制该成员，而不是仅仅返回它。

来源

2016-11-07 13:17:14

那么，你会有文档。如果你描述了这种行为，并且它在你的api中是一致的，那么它不会是真正意想不到的，不是吗？另外，节省带宽怎么样，你能接触到吗？这没关系吗？在web开发中，人们真正关心每个kb，因此缩小响应大小，因此加快应用程序似乎很重要。差异显然会越大，返回的数组越大，过滤器越多，我认为在某些情况下，这可能非常重要。重复相同的信息客户端已经知道在每个对象看起来很浪费。 – Erndob

资源应该包含相同的字段，而不管它是如何获取，过滤或不是。这就是我对REST的理解。当然你可以自由地实现你想要的任何东西。大小确实很重要，但是您的示例可以保存什么 - 20个字节？我要做的是：允许客户端指定应该返回的字段。在这种情况下，客户端负责节省带宽。 –

没有“正确的”答案，这取决于一般的API设计，应该是您的决定。

我同意Thorstens的意见，你应该返回整个资源 - 这是接近一般REST的想法。当你这样做时，你也可以实现一些像在FB API中一样选择字段的机制：请参阅this paragraph的“选择字段”部分。

来源

2016-11-07 13:19:19

您应该在回复中保留颜色。将会有多个方面的原因：

你确保你所请求的就是你
如果有在页面不同颜色的多个项目，你不要让客户照顾根据颜色“过滤”物品
您有更“安全”的回应。例如，客户端请求蓝色，但是然后恶意脚本会以红色项目操作此响应。

来源

2016-11-07 13:21:28

为什么客户会重新回复？它被过滤了服务器端，客户端期望所有返回的项目都是“红色”，否则服务器代码被破坏 – Yazan

您不必重新过滤响应，但客户端有责任知道来自响应。 –

客户端将已经在URL'.../items/red'中发送过滤器数据，所以客户端不必重新检查响应（是我要求的吗？） – Yazan

REST风格的API设计。如果请求带有过滤器，您是否也应该返回该过滤器的值？

回答

相关问题