8

我正在学习 REST 原则，但我对使用复杂资源有疑问。

假设我们有两个资源，Foo 和 Bar，对于每个 Foo，我必须有一个 Bar。我想使用我的 API 让开发人员清楚地了解 bar 从 foo 的依赖关系，所以：

1) 我将使用从 Foo 实例到 Bar 实例的链接，反之亦然

GET /foos/1
Foo: {
    'name': 'Foo instance',
    'rel_bar': '/foos/1/bar'
}


GET /foos/1/bar
Bar: {
    'name': 'Bar instance',
    'rel_foo': '/foos/1',
}

2) 我将使用一个 URI 模板来显示从 Foo 到 Bar 的依赖关系（这仅适用于人类，因为 URI 对于 REST 应该是不透明的）。

/foos               --> Foo resource collection
/foos/{foo_id}      --> An instance of a Foo resource
/foos/{foo_id}/bar  --> The bar instance associated to the foo instance foo_id

所以再一次，没有相应的 foo 就没有 bar。

现在我想创建一个 Foo 资源。

POST /foos
{
   'name': 'Yet again another foo instance',
}

并让服务器创建对应的 Bar 默认（或空）资源，这样下一次读取就会给出：

GET /foos/2
{
   'name': 'Yet again another foo instance',
   'rel_bar': '/foos/2/bar'
}

和...

GET /foos/2/bar
{
   'name': null,  --> Let's say that null is the default value.
   'rel_foo': '/foos/2/bar'
}

'RESTfully 正确' 这样做吗？我的担忧是：

  1. 让服务器自动创建相关资源是否正确？或者我应该分两步拆分 Bar 和 Foo 的创建？
  2. POST 一个表示（只是“name”属性）并返回一个不同的表示（“name”和分配的“rel_foo”）是正确的。

我个人的想法是，既然 Bar 没有 Foo 就没有意义，可能是的，我应该让服务器来创建它。

任何的想法？

4

1 回答 1

5

我不确定您所描述的是否是独立资源 Foo 和 Bar。你说：

对于每个 Foo 我必须有一个 Bar

连同您描述的“JSON”和 URI，我将其称为子资源关系：对于每个 Foo，必须有一个且只有一个 Bar，该 Bar 不能存在于该 Foo 之外。

如果这种解释是正确的，我会保留您的 URI，但将表示更改为：

GET /foos/1

{
    'name': 'Foo instance',
    'Bar': {
        'name': 'Bar instance'
    }
}

请注意，我没有包括不必要的rel_bar和。rel_bar

您只能 GET使用 Bar 子资源：

GET /foos/1/bar

{
    'name': 'Bar instance'
}

请注意，在此表示中，没有返回父 Foo 的链接元素。这样的链接是不必要的，因为 URI 使资源/子资源关系清晰。

你的问题1：

让服务器自动创建相关资源是否正确？或者我应该分两步拆分 Bar 和 Foo 的创建？

是否在某个后端实际创建了 bar 子资源并不重要。重要的是它作为 Foo 表示的成员是可访问的。仅POSTFoo 表示后， Bar 子资源的表示将具有您描述的默认值。它可以在以后被覆盖：

PUT /foos/1/bar

{
    'name': 'A name for this Bar'
}

你的问题2：

POST 一个表示（只是“name”属性）并返回一个不同的表示（“name”和分配的“rel_foo”）是正确的。

对，那是正确的。客户可以POST或PUT不完整的表示。重要的是始终以一致的方式处理这种不完整的表示。我发现为每个新的 Foo 创建一个 Bar 子资源是完全可以接受的。

于 2012-11-06T20:36:50.543 回答