Question

我正在学习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的依赖关系（这仅适用于人类，因为REST应该对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就没有吧。

现在我想创建一个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'
}

'RESTful correct'这样做吗？我担心的是：

让服务器自动创建相关资源是正确的吗？或者我应该分两步拆分Bar和Foo的创作？
对POST一个表示（只是'name'属性）是正确的，然后获取另一个（'name'和指定的'rel_foo'）。

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

有什么想法吗？

Answer 1

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

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

与'JSON'和你描述的URI一起，我称之为子资源关系：对于每个Foo，必须有一个且只有一个Bar不能存在于此Foo之外

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

<强> GET /foos/1

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

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

你可以 GET只有Bar sub-resrouce：

<强> GET /foos/1/bar

{
    'name': 'Bar instance'
}

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

您的问题1：

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

如果某个后端实际上是创建了条形子资源，那么这一点并不重要。重要的是它可以作为Foo表示的成员到达。在仅POST Foo表示之后，Bar子资源的表示将具有您描述的默认值。它可以在以后重写：

<强> PUT /foos/1/bar

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

您的问题2：

对POST一个表示（只是'name'属性）是正确的，然后获取另一个（'name'和指定的'rel_foo'）。

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

REST和自动创建相关资源

1 个答案: