REST and automatic creation of the corresponding resource

Question

I study the principles of REST, and I have doubts about working with complex resources.

Let's say we have two resources: Foo and Bar, and for each Foo I have to have a bar. I want the bar dependency on foo to be clear to developers using my API, therefore:

1) I will use links from Foo instances to Bar instances and vice versa

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) I will use a URI pattern that shows the dependency on Foo to Bar (this is easy for people, since the URI should be opaque to 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 

So again, there is no bar without the corresponding foo.

Now I want to create a Foo resource.

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

And let the server create the appropriate bar by default (or empty) the resource, so the following reading will give:

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

BUT...

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

Is "RESTfully correct" to do this? My problems:

• correctly allow the server to automatically create a linked resource? Or should I separate the creation of Bar and Foo in two steps?
• is a valid POST representation (name attribute only) and returns another ("name" and assigned "rel_foo").

My personal thought is that since Bar doesn't make sense without Foo, maybe yes, I should let the server create it.

Any idea?

Answer 1

I'm not sure what you are describing are the independent resources of Foo and Bar. You speak:

for every foo i have to have a bar

Together with the "JSON" and URIs that you describe, I would call this a sub-resource relation: for each Foo there should be one and only one bar that cannot exist outside of this Foo.

If this interpretation is correct, I would keep your URIs, but change the representation to this:

GET /foos/1

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

Please note that I did not include rel_bar and rel_bar , which are not needed.

You can get only sub-resrouce enabled:

GET /foos/1/bar

 { 'name': 'Bar instance' } 

Note that in this view, the link element does not return to the parent Foo. Such a reference is not necessary, since the URI makes the resource / subresource relationship clear.

Your questions 1:

Is it correct for the server to automatically create a linked resource? Or should I separate the creation of Bar and Foo in two steps?

It doesn’t matter if the sub-resource of the bar is actually created in some backends. The important thing is that it is available as a member of the Foo view. After the POST view is presented to Foo, the sub-resource view of Bar will have the default values ​​that you describe. Later it can be redefined:

PUT /foos/1/bar

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

Your questions 2:

is correct for the POST representation (name attribute only) and returns another ("name" and the assigned "rel_foo").

Yes, that's right. The client may POST or PUT unresolved presentation. It is important to always deal with such incomplete representations. I am very pleased that a Bar sub-resource is being created for each new Foo.