RESTful web服务：通过组合其他资源来创建新资源：提供ID还是URI？

Question

从RESTful Web服务（通过GET）获取项目集合时，每个项目的表示形式（例如在JSON中）通常包含项目的资源标识符。这可以是资源的ID，也可以是通常包含ID的整个URI。

如果客户端需要与表示单个项的远程资源进一步交互，则需要此标识符（ID或URI）。许多人似乎认为提供整个URI而不仅仅是ID是一种很好的做法，这样客户机就与URI构造无关（例如，这就是Miguel Grinberg在本文中所写的）。

但是，如果要组合多个项目以创建新资源，应该怎么做呢？然后，客户机需要告诉服务器要组合哪些项目。最后，服务器需要一个ID列表来处理请求。假设客户机首先检索到每个项目的URI——为了再次提取原始ID，您会在哪里执行URI解析：在客户机中还是在服务器中？

示例：客户端在GET请求中检索了页面集合。每个页面项都使用一个URI（包含ID）标识自己：

{
  "pages": [
    {
      "content": "bla bla",
      "uri": "/pages/1"
    },
    {
      "content": "that is no interesting content",
      "uri": "/pages/2"
    },
    ...
  ]
}

现在假设客户机指示服务器创建一个结合多个页面的新资源：一本书，由第1页和第2页构建。POST请求正文可以包含ID或URI：

{
  "title": "A Boring Book",
  "pages": [1, 2]
}

或

{
  "title": "A Boring Book",
  "pages": ["/pages/1", "/pages/2"]
}

在第一种情况下，客户端需要知道URI的结构，并在发送请求之前提取ID。在第二种情况下，服务器需要从URI中提取ID。

一方面，我喜欢资源仅由URI在客户端表示的想法。另一方面，我也喜欢保持简单实用，为什么我们要在上下文清晰且只需要ID的情况下将整个URI发送给服务器（书籍创建不会直接作用于页面资源）？

你喜欢什么？为什么？还是你认为这真的不太重要？

您认为以下方法是一个好的折衷方案吗？客户端从URI中提取ID，方法是从右到左解析URI，并在最右边的斜杠后提取数字，即假设某个URI结构，而无需对整个路径进行硬编码。

Answer 1

我认为客户端应该从服务器接收绝对URL，并且只使用这些URL而不进行任何修改。因此，我甚至会比上一个例子更进一步：

{
  "title" : "A Boring Book",
  "pages" : [ "http://.../pages/1", "http://.../pages/2" ]
}

如果需要，只有服务器负责从URL提取ID。