Михаил

Самый простой путь: в том месте где вы загружаете сущность поста из БД добавить проверку, что текущий авторизованный пользователь является автором поста.

Авторизацию пользователя можно сделать разными способами, тут гуглить Spring Security - это все целиком про авторизацию и проверку прав доступа.

Например, вот статья о сессиях в спринге, думаю в качестве отправной точки сгодится.

• В терминах операционной системы (windows), приложение = программа.
  
• С точки зрения спринга, если не вдаваться глубоко в детали, это тоже самое. Приложение = программа, написанная с использованием Spring. Это может быть сайт, это может быть некий сервис, это может быть вообще консольная команда.
  
• С точки зрения VK, приложение - это некий сайт (или его часть), использующий API VK. То есть дополнение к ВКонтакте
  

Не совсем понятно какая у вас цель. Если добавить на своем сайте возможность создавать дополнения к нему, то есть приложения, то в первую очередь нужно определиться какие возможности этим приложениям будут доступны. А затем уже создавать API для них. Форма для приложения - это по сути обычная форма, после обработки данных из которой добавляется запись в БД вашего сайта о существовании приложения и его атрибутах (в частности токене для авторизации, чтобы вы понимали какое приложение шлет запросы вашему API).

То есть, говоря о "приложении" нужно понимать контекст в котором это слово употребляется.

final List<AdImage> imageList = new ArrayList<>();
for (...) {
...
  final AdImage image = new AdImage(...); //Аналогично тому как вы создаете Ad
  imageList.add(image);
...
}
ad.setImages(imageList);

Еще вопрос можно ли в в AdImages избавить от колонки id?

Зачем от нее избавляться? Если убирать её - то что будет идентификатором изображения вместо нее?

И еще момент: вы либо не выложили полный код ваших Entity, либо у Ad нет конструктора, который вы пытаетесь вызвать.

1. Подумать - что это за странное разбиение на микросервисы, которые оперируют связанными данными? Возможно тут что-то не так (и сильно не так)
2. Подумать - не стоит ли данные денормализовать и сдублировать данные о пользователе (или работе) в какой-то из двух микросервисов.
3. Выгребать все данные без фильтрации и делать фильтрацию и пагинацию уже на сервисе-потребителе. Но тут все зависит от объема данных. Если там десятки-сотни мегабайт - это окажется очень грустно.

Но лично я бы в первую очередь заподозрил необходимость рефакторинга. И, возможно, слияния этих микросервисов.

Неважно. В любой момент вы можете собрать ваш проект в docker image и далее использовать его любым угодным вам образом.

В случае spring (и вообще java/kotlin), см. jib-gradle-plugin или jib-maven-plugin в зависимости от используемой системы сборки.

Так запрос же асинхронный. То есть вы его запускаете и говорите "вот когда данные придут - запиши их в список". И не дожидаясь пока запрос выполнится - возвращаете список (который, разумеется, пустой - запрос же еще в процессе выполнения).

Поэтому, если уж вы начали использовать асинхронные запросы - надо жить в асинхронном мире дальше, везде протаскивая Mono и Flux.

Либо переходить на Kotlin с его корутинами (которые прекрасно интегрируются с Mono/Flux)

А зачем вам учебный материал по спрингу на котлине?

Весь учебный материал по спрингу актуален для котлина. Переложить Java на Kotlin - даже не просто, а очень просто (даже IntelliJ IDEA умеет автоматически конвертировать Java в Kotlin). Поэтому берите Java и не мучайтесь (все равно при использовании котлина и спринга джаву знать необходимо т.к. постоянно будете натыкаться на джавовские библиотеки)

Controller является частью приложения, соответственно пакет Controllers должен находиться внутри пакета application

Это, конечно, можно править аннотациями спринга, но вообще SpringBootApplication ищет компоненты (контроллеры, сервисы, репозитории и т.д.) "вниз" от класса приложения. Соответственно в вашей структуре оно контроллер просто не находит и не создает бин контроллера.

Альтернатива - см. аннотацию ComponentScan

Если вас тормозит именно внешний API и этот API нормально выдержит большое количество одновременных запросов - то асинхронность более чем поможет. Рекомендую посмотреть Webflux и/или корутины на котлине.

Скажите, а вас разный регистр буковок в запросе и в ответе (хотя там одни и те же DTO) ни на какие мысли не наталкивает?

А меня вот наталкивает, что Jackson сериализует и десериализует поля с именами из маленьких буковок. Либо сконфигурируйте Jackson чтобы он понимал большие - либо шлите запрос с маленькими буковками.

Интерфейсы нужны для возможности замены реализации не затрагивая основной код. При использовании интерфейсов основной код ничего не знает об деталях реализации (слабая связанность). Соответственно, реализацию можно вынести в отдельный модуль (изолировать сложность). Если основной код ссылается непосредственно на класс, содержащий реализацию (сильная связанность), то сложность программы возрастает и сопровождение программы усложняется. Поэтому интерфейсы особенно нужны на границах подсистем.

Если реализация отделена от основного кода, то становится легко подменить её в тестах, например, подсунуть in memory реализацию, вместо БД. См. fake object (не путать с mock). Это еще один важный плюс интерфейсов.

Возможно, в простых программах интерфейсы не слишком нужны. Но, поскольку вы говорите об учебном примере, то использовать их (приучая сразу к хорошему, правильному стилю) - это правильно.

React-приложение должно послать те данные, которые нужны спрингу, чтобы сконструировать Principal. Распространенный вариант - JWT-токен. Либо идентификатор сессии. Либо еще что-то, нужно смотреть конкретику как у вас сконфигурирован Spring Security в приложении.