REST 和自动创建相关资源

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this 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 的依赖关系(这仅适用于人类，因为 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'
}

'REST 完全正确' 这样做吗？我的担忧是:

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

发布一个表示(只是“名称”属性)并返回一个不同的表示(“名称”和分配的“rel_foo”)是正确的。

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

任何的想法？

Answer 1

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

for every Foo I must have a Bar

连同“JSON”和您描述的 URI，我将其称为 子资源关系:对于每个 Foo 必须有一个并且只有一个 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:

is correct to let the server to automatically create a related resource? Or should I split the creation of Bar and Foo in two steps?

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

PUT /foos/1/bar

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

您的问题2:

is correct to POST a representation (just the 'name' attribute) and GET back a different one ('name' and the assigned 'rel_foo').

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