我目前正在开发一个REST API,该API公开了不同的端点。
这种端点的一个例子是
/users/{userId}/transactions/type/{transactionType}/all
此端点返回用户特定交易类型的所有交易的列表。
我还有一个端点,用于从用户检索特定类别的所有交易,该端点将访问该端点
/users/{userId}/transactions/category/{categoryId}/all
我的问题是这是一个好方法还是拥有一个端点并具有可选的查询参数会更好?
例如
/users/{userId}/transactions/all?categoryId={id}&transactionType={type}
/users/{userId}/transactions/all?categoryId={id}
/users/{userId}/transactions/all?transactionType={type}
/users/{userId}/transactions/all
后者的好处是您将能够按类别和类型过滤交易,而不仅仅是一个。但这是一个好的设计还是有更好的方法?
答案 0 :(得分:1)
是的,使用查询参数来过滤事务是一种很好的方法。 但是要遵循REST的想法,最好更改端点。
来自
/users/{userId}/transactions/type/{transactionType}/all
到
/users/{userId}/transactions?transactionType={transactionType}
从端点可以阅读以下内容: 该查询将返回值为userid的用户所有具有transactionType的交易。 因此,查询将返回的值应保留在端点的末尾,所有过滤器均为查询参数。在您的情况下,查询返回事务,因此事务位于末尾,然后是查询参数。
并且您在REST端点中不需要“全部”一词。
/users/{userId}/transactions?categoryId={id}&transactionType={type}
答案 1 :(得分:0)
除标识符应符合RFC 3986的事实外,REST没有提供有关URI设计的指南。
/x/y/z
/x?y=z
这两个标识符都是 fine 。
具有application / x-www-form-urlencoded键值对的URI的优点是Web浏览器具有HTML表单处理的标准。表单就像一种URI Template。
当您具有标识符层次结构时,路径段很方便,因为URI标准包括relative resolution和点段。
在REST中,标识符在功能上是不透明的-通用客户端不会从URI中提取任何语义信息。这样服务器就可以自由地将所需的任何信息编码到标识符中。
这意味着,对于您自己的资源,您可以选择自己喜欢的任何URI设计。最常见的选择集中在易于路由(在您碰巧选择的任何服务器实现中)和符合本地设计标准的东西上(通过这种方式,URI与变量名很像-编译器/解释器不一样)关心,但是执行代码审查的人确实关心)。