RestAPI, маршруты, отношения, модели?

Question

[to_east]

Приветствую участников тостера!

Если взять к примеру такую схему отношений постов и картинок (OneToMany):

Posts
	title
	content

Images
	src
	post_id

Как будет логически правильней организовать бизнес-логигу и маршруты api на бекэнде, при создании нового поста например.
Мне видится такой вариант сценария:

Юзер заполняет поля title и content на клиенте, а также загружает необходимые картинки, клиент делая запрос POST по маршруту /images/uploads/ с Content-Type: multipart/form-data, получает json с успешно добавленными картинками, что-то типа такого:

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

Клиент выводит эти картинки как превьюхи.
После этого Юзер нажимает кнопку submit, срабатывает хендлер, клиент сериализует title и content данные и отправляет их POST запросом на /api/posts/, если данные валидны то в ответе идет примерно такое:

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

Клиент принимает id добавленного поста и делает уже другой запрос для связывания поста с картинками, предположим метод будет PATCH или PUT на маршрут /api/posts/1/images/, потому как картинки уже загружены на сервер и имеются в базе, в теле запроса можно отправить то что прислал нам /images/uploads/.
Проблем нет когда такая простая схема, а если необходимо добавить еще к этому связь постов к тегам при этом еще нужно обеспечить валидность данных каждой модели, чтобы пост создался корректно.
Или же лучше отправлять целиком данные о посте - title, content, images, tags, ...?
Еще приходила такая мысль конструировать форму динамически на клиенте и отправлять как форму а не как json но получать при этом json о статусе выполненного запроса, но это уже будет не restful, а наверное просто json api.
Вобщем кто как делает, буду рад услышать все за и против.

Answer 1

[grinat]

В ресте нет никаких спецификаций, есть диссертация с которой все пошло, и куча разных вариаций форматов, которые продвигают для использованию, вот например как один из форматов предлагает решать твои проблемы: https://jsonapi.org/format/#crud-updating-resource... В каком-то проекте так удобно, в каком-то не удобно, в каком-то нужно что-то еще.
Фул он или не фул это вообще не важно, и в оригинале никаких json не было, вроде он на тот момент даже еще и не был придуман. Поэтому делай как удобно, передавай и принимай в формате который удобен(почти все фреймворки из коробки корректно обрабатывают json,xml и form data), а все эти рассуждения о ресте, это как разговоры о том что такое ооп.