Как управлять версиями API REST с запасом данных весны?

Question

• Каким образом можно поддерживать поддержку версий API в Spring Rest Data?
• Можно ли это сделать с repository-resources или мне нужно использовать RepositoryRestController?

Я не могу найти ничего о API управления версиями в Официальном сайте Spring Rest Data

Я нашел Joshua Long presentations about REST APIs with Spring

версии API могут быть реализованы с помощью одного из двух способов:

• через API URI: https://api.foo.com/v1
• Через типы носителей: application/vnd.company.urapp-v3 + json

Первый подход имеет некоторые проблемы, описанные here

Answer 1

Это интересная тема. В документации по Spring-data-rest не упоминаются лучшие практики для управления версиями.

Из того, что я знаю о Spring-data-rest, невозможно реализовать управление версиями носителей без реализации пользовательских контроллеров.

Но, конечно, текущая функциональность позволяет URI на основе управления версиями:

• всегда включают в себя версию в Вашей организации - либо в имени пакета или класса - например, com.company.v1.MyEntity или com.company.MyEntityV1

• в использовании хранилища @RepositoryRestResource, чтобы содержать версию в URI

  @RepositoryRestResource (путь = "/ v1/магазины")

Таким образом, вы всегда можете создать новый объект когда вы нарушаете изменения в API и используете новый репозиторий для раскрытия новой версии API.

EDIT: Мы обсуждали эту тему в команде и несколько новых интересных мыслей на REST API версий придумал, что я хотел бы поделиться.

Я думаю, мы все согласны с тем, что изложенная выше идея не изящна. Он вводит много дубликатов кода, и когда вы отключите старую версию, вы должны удалить ее из базы кода - что может быть сложнее, чем вы думаете. Тем временем вы должны поддерживать две версии в базе кода. Вы всегда хотели бы этого избежать.

Итак, каковы альтернативы. Вы можете делать то, что мы часто делаем в мире микросервисов - сложность задачи для инфраструктуры. Создание и запуск новых рабочих сред довольно просто в инфраструктуре микросервисов, поэтому мы можем выбрать запустить две разные версии одной и той же службы. Старая версия, предоставляющая старую версию API и новую, поддерживающую нашу новую версию. Шлюз API может взять на себя маршрутизацию, например.на основе HTTP-заголовков (Accept или Content-Type) или информации о версии, содержащейся в URI. И если вы хотите избавиться от старой версии, вам просто нужно отключить время выполнения старой версии, и все готово. Я думаю, что это может быть изящное решение, обеспечивающее чистоту кода.

Есть вероятность, что ваша инфраструктура уже поддерживает различные версии одной и той же службы для поддержки blue-green deployment scenarios. Это означает, что у вас уже есть возможности маршрутизации, которые вы могли бы наращивать.

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