时间戳

首页 > 解决方案 > 允许对所有资源的属性进行排序？

rest - 允许对所有资源的属性进行排序？

问题描述

我是第一次设计 REST API 并正在实现排序。

设计良好的 REST API 是否应该允许对每个属性进行排序，或者是否可以将排序限制为仅属性的子集？

如果一个子集没问题，我该如何处理要求对另一个属性进行排序的查询：我是默默地忽略它还是应该抛出/返回 400？

标签： restsorting

解决方案

允许对所有资源的属性进行排序？

通常的答案不是操纵（排序）资源的表示，而是创建一个具有排序表示的新资源。

GET /1a587d4e-4443-49ce-9195-20e821e67f83

GET /1a587d4e-4443-49ce-9195-20e821e67f83?sort=name

从通用组件的角度来看，这是两种不同的资源。它们可能彼此完全独立，或者它们可能是相同基础数据的不同表达。

只要您不需要通用组件的两种不同表示形式的副本始终一致，这就可以正常工作。因为资源具有不同的标识符，所以它们每个都有自己的缓存策略，使一个无效不一定会使另一个无效。

有时使用的另一种方法是将区分作为媒体类型的一部分，而不是资源标识符的一部分

GET /1a587d4e-4443-49ce-9195-20e821e67f83
Accept: application/prs.unsorted+json

GET /1a587d4e-4443-49ce-9195-20e821e67f83
Accept: application/prs.name-sorted+json

换句话说，使用 HTTP 的内容协商功能来确保客户端获得适当的表示。该方面解决了您可能遇到的一些一致性问题，以权衡“客户端如何确定要包含在 Accept 标头中的内容类型”的额外复杂性。

我的问题的要点是：如何对资源集合进行排序，例如 GET api/orders?sortby=createdOn。我是否需要允许对订单的任何属性进行排序，或者我可以忽略客户对其中一些属性进行排序的请求（例如 GET /api/orders/sortby=itemCount

从 REST 的角度来看，这完全取决于您。源服务器是任何给定目标 uri 是否有意义（即，该标识符在任何给定时刻是否可用）的权威。

您可以决定是否应该有一个资源来显示按最后修改日期、订单总额、折扣或任何您喜欢的东西排序的订单。

推荐阅读