获取子集列表的REST最佳实践

拉尔夫,

特定的URI模式与应用程序的RESTful程度是正交的。

关于宁静,重要的是客户 发现 如何构造URI 在运行时 . 这可以通过表单或URI模板实现。两个超媒体控件都告诉客户端可以使用哪些参数以及将它们放在URI中的位置。

为了使其能够重新工作,客户机和服务器必须在设计时知道可能的参数。这通常是通过使它们成为链接关系规范的一部分来实现的。

例如,您可以定义一个“我的子集”链接关系,使其具有链接到集合子集的含义,并用它定义以下参数:

列表类型、日期、用户ID。

在链接模板中,spec可以用作

<link rel=“my subset”template=“/listType/date/patients;user user id”/>gt;

请注意,如何将URI中的实际参数名与指定的参数名分离。user id的值延迟绑定到uri参数user_id。

这使得可以在不影响客户端的情况下更改URI参数名。

您可以查看OpenSearch描述文档( http://www.opensearch.org )看看这在实践中是如何做到的。

实际上,您应该能够为您的用例充分利用OpenSearch。特别是预先定义查询的能力将允许您在“表单”中描述特定的子集。

但你自己去看看,然后再问回来:—)

简

我建议您使用以下URL结构:

/appointments;user_id=1234;date=2010-02-22

为什么?我选择 /appointments 因为它简单明了。(如果您有多种约会,请在评论中告诉我,我可以调整我的答案。)我选择分号,因为它们不表示用户ID和日期之间的层次结构。

还有一件事,你没有理由只局限于一个网址。拥有多个引用同一资源的URL结构是很好的。所以你也可以使用:

/users/1234/appointments;date=2010-02-22

返回类似结果。

也就是说,我不建议使用 /dates/2010-02-22/appointments;user_id=1234 . 为什么?实际上,我不认为 /dates 指资源。日期是约会的一个属性,但它本身不是一个名词(也就是说,它不是一种一流的事物)。

我能理解大卫詹姆斯的回答。
您的URI的格式可以像他建议的那样:

/appointments;user_id=1234;date=2010-02-22

和/或

/users/1234/appointments;date=2010-02-22

同时仍然保持资源的URI的可发现性(运行时)(如JanAlgermissen建议的那样)。