Creating related objects in a REST api in Symfony

Question

What is the correct way to create an object that will be associated with others? I cannot find a source of information about how this should be done or how it is done in Symfony with the FOSRestBundle package.

Reference Information:

Allows you to have a Car object with Wheel objects.

How to create a car with wheels on one request?
url: foo.com/cars POST
data: {car:{name="porsche", wheels:[{name:"fr"}, {name:"fl"}] }}
Is this right how to do it? I read a few things about LINK and UNLINK http methods, but for this you need to send a few requests to create all the wheels and then link them together.

How to create a wheel with several cars?
url: foo.com/wheels POST
data: {wheel:{name="super wheel", cars:[{id:1}, {id:2}] }}
In this situation, it is advisable to use the LINK header. But after reading this article, this will require parsing LINK headers for all POSTS and PUTS, which makes it expensive and cumbersome.

EDIT

I wrote to the author of the mentioned article. Here is his answer:

I think you can send data containing both your wheels and cars in one request. The most important thing here is to be pragmatic. There are no “clear” rules for building a REST API.

LINK / UNLINK are useful when resources already exist and you want to “link” them, in other words, you want to add a “relationship” between them, for example, friendship for users.

About your second question, if there are cars, you can, firstly, create your own wheel and “tie” it to your cars. But this will mean two requests for this action (you can add several link headers in one request), or better you could send one POST request with link headers: one request for all of them: p

Another option would be to link to the vehicle IDs in your wheel data. I think this is good too.

Answer 1

We had the same discussion recently.

There is something to be said for clarity and clean architecture, where you separate our resources from relationships and so on. There is also something that can be said about not making 1000 requests and collecting things that belong together.

Our final decision was very similar to yours. Another solution would be to never include the relationships in the resources when they are inserted and have a separate API endpoint for creating the relationships (e.g. POST / cars / 1 / wheels / fl)

In which direction you will mainly depend on the requirements for the logic and applications of the domain. As soon as you have a circular relationship m: n, you will have big problems with the approach that you (and we) choose. For simpler and more hierarchical relationships, this is a great way to do this.

Answer 2

As you quoted: "There are no" clear "rules for building a REST API."

I usually use the form to validate my data in my APIs, so I already have my parameters. I use this because I have to write only one endpoint (used both in the API and the ability to display html interfaces). A form can expect an identifier or sub-object (or both).

I am not saying that you should use my point of view. But I say: your API, your rules (this is for the client to adapt, but you have to think like a client too in order to build you an API).