用于单/多资源 GET 的 RESTful Web URI 设计
我已经在这个网站和网上寻找答案，但还没有完全找到解决这个问题的最佳方法。
举个例子，假设我有以下 REST API
单一资源 REST API 很简单：
/car/{id} -->通过id取车
获取汽车列表的多个资源：
/cars;ids={id1,id2,id3 等} -->按 ID 获取汽车列表
/cars;list-id={listId};count=5 -->获取由保存的列表 ID 定义的汽车 在云端
/cars;relatives={id};count=5 -->获取与汽车相关的汽车 由id指定
list-id 可以指定要返回的任意元素列表。 /cars 将只返回该列表中定义的汽车。
注意：矩阵参数relatives、ids 和 list-id 不能全部在单个 GET 请求中使用。例如，如果 ids 和 list-id 同时出现，则 ids 优先。
问题：是否应该重新设计？如果是这样，怎么办？谢谢。
Possible Duplicate:
Rest URL design - multiple resources in one http call
I have looked for answers on this site and the net, but haven't quite figured out the best way to approach this problem.
As an example, say I have the following REST API
Single resource REST API is straightforward:
/car/{id} --> get car by an id
Multiple resource get for a list of cars:
/cars;ids={id1,id2,id3 etc} --> get list of cars by ids
/cars;list-id={listId};count=5 --> get cars defined by a list id saved
in the cloud/cars;relatives={id};count=5 --> get cars that are related to the car
specified by id
A list-id can specify an arbitrary list of elements to return. /cars will just return cars defined in that list.
Note: the matrix params relatives, ids, and list-id cannot all be used in a single GET request. E.g if ids and list-id both appear, then ids will take priority.
Question: Should this be redesigned? And if so, how? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您将一辆车视为只有一辆车的列表 ID，该怎么办？列表 ID 可以引用一辆或多辆汽车。为此，列表 ID 和汽车 ID 必须共享相同的“域”。其中一个并不优先于另一个，因为它们实际上是同一件事 - 一张汽车列表。
GET /car/{id} 可以是一辆汽车或一系列汽车。
GET /car/{id}/lated 将返回与汽车 ID 中的汽车列表相关的汽车列表。但这个列表还没有自己的 ID。
POST /car/{id}/lated 将返回汽车列表的列表 ID。然后可以将其与 GET /car/{id} 一起使用，以返回同样通过 GET /car/{id}/lated 间接检索的汽车列表。
What if you view a car as a list ID with just one car? A list ID could then refer to one car or multiple cars. For this to work a list ID and a car ID have to share the same 'domain'. One doesn't take priority over the other because they are actually the same thing - a list of cars.
GET /car/{id} could be one car or a list of cars.
GET /car/{id}/related would return a list of those cars related to the list of cars in the car ID. But this list would have no ID of it's own (yet).
POST /car/{id}/related would return a list ID for the list of cars. That could then be used with GET /car/{id} to return the same list of cars that was also retrieved indirectly with GET /car/{id}/related.