我们正在创建一个REST API，允许我们的客户端获取他们的许可内容，我试图通过创建一个资源（delivery）来确定是否有可能通过我们的客户隐藏一些内部复杂性然后映射到内部资源的集合（许多“批次”）。
我们的业务流程规定，当我们为客户准备内容时，它目前由内容类型分隔，我们称内容类型为“批次”（尽管我们会更改此过程）在接下来的12-24个月内，为了更好地与“交付”的概念保持一致。除了在策展人的心目中，批次在历史上彼此无关。策展人为所有批次生成xml文件，并通过电子邮件将它们捆绑在一起，从而提供所有内容都是单次交付的一部分的印象。
问题是对于想要使用我们的内部“批次”系统检索特定交付（例如2014年12月或2016年5月）的内容的客户，强制客户端确定哪些批次关联与期望的交付。 另类我想象的是，我们创建“交付”作为资源，在幕后，将映射到所有成分批次。
关键点是因为我们没有delivery的内部表示（尚未），因此我们没有预先存在的ID来关闭。但是，交付的due-date是可靠的唯一标识符。它对客户端有意义，可用于将批次与delivery。
所以我的问题是：我们可以使用截止日期来代替ID吗？像/v0/deliveries/20160530这样的东西可以检索2016年5月30日发布的内容？ （有人认为这可能会违反RESTful原则。）
答案 0 :(得分：2)
REST没有说明哪些网址应该是什么样的。任何唯一标识符都可以。有些API使用UUID，因为他们不想透露他们所拥有的资源类型的数量。
答案 1 :(得分：0)
这听起来似乎可以更好地呈现为一种搜索。例如，如果可以在/v0/batches/(id)访问您的批次，则可以使用/v0/batches?delivered=20160530获取该日期交付的批次列表。这可以在将来扩展，以允许搜索其他标准。