RestAPI, routes, relationships, models?

Question

RESTful API

Greetings Toaster Members!
If we take for example the following scheme of relations between posts and pictures (OneToMany):

Posts
  title
  content

Images
  src
  post_id

How would it be logically correct to organize business logic and api routes on the backend, for example, when creating a new post.
I see this scenario:
The user fills in the title and content fields on the client, and also uploads the necessary images, the client makes a POST request along the /images/uploads/ route with Content-Type: multipart/form-data, receives json with successfully added images, something like this:

{
  "status": "success",
  "images": [
    {
      "id": 1,
      "src": "/uploads/foo.png"
    },
    {
      "id": 2,
      "src": "/uploads/bar.png"
    }
  ]
}

The client displays these pictures as previews.
After that, the User presses the submit button, the handler fires, the client serializes the title and content data and sends them with a POST request to /api/posts/, if the data is valid, then the response goes something like this:

{
  "status": "success",
  "id": 1
}

The client accepts the id of the added post and makes another request to link the post with images, suppose the method is PATCH or PUT to the /api/posts/1/images/ route, because the images have already been uploaded to the server and are in the database, in the request body you can send what was sent to us by /images/uploads/.
There are no problems when such a simple scheme, and if you need to add to this the connection of posts to tags, you still need to ensure the validity of the data of each model so that the post is created correctly.
Or is it better to send the whole post data - title, content, images, tags, ...?
Another thought came to construct the form dynamically on the client and send it as a form and not as json, but at the same time receive json about the status of the completed request, but this will no longer be restful, but probably just json api.
In general, whoever does it, I will be glad to hear all the pros and cons.

Answer 1

There are no specifications in the rest, there is a dissertation from which everything went, and a bunch of different format variations that are promoted for use, for example, here is how one of the formats suggests solving your problems: https://jsonapi.org/format/#crud-updating- resource... In some project it is so convenient, in some it is not convenient, in some you need something else.
Whether he is full or not is not important at all, and in the original there were no json, it seems that at that time it had not even been invented yet. Therefore, do as it is convenient, send and receive in a format that is convenient (almost all frameworks correctly process json, xml and form data out of the box), and all this reasoning about rest is like talking about what oop is.