REST和自动创建相关资源

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'
}

'RESTfully correct'这样做吗？我担心的是:

1. 让服务器自动创建相关资源是正确的吗？或者我应该分两步拆分Bar和Foo的创作？
2. POST一个表示(只是'name'属性)是正确的,并且GET返回另一个('name'和指定的'rel_foo').

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

任何的想法？

Answer 1

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

对于每一个Foo,我必须有一个酒吧

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

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

GET /foos/1

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

请注意,我没有包含rel_bar和rel_bar不必要的.

你可以 GET只酒吧子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'属性)是正确的,并且GET返回另一个('name'和指定的'rel_foo').

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