Хорошие инструменты для создания версий моделей REST для Java

Question

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

• Мой pojo + версия 1.0 config / transformer => Сервис, доступный с 1.0 моей модели
• Мой pojo + версия 1.1 config / transformer =>Сервис доступен с 1.1 моей модели

В моем конкретном случае мне не нужно выполнять обратное преобразование, так как мой сервис REST только обеспечивает поиск данных и никогда не хранит вещи, но я не противиспользуя инструмент, выполняющий оба действия: -)

Решение, которое я рассматриваю, заключается в добавлении пользовательских аннотаций в мое pojo (версия + имя) и создании генератора кода, который будет генерировать JSON / XML на основе моего pojo на основе версиичисло.Хотя здесь я чувствую, что заново изобретаю колесо.

Редактировать: Вот пример изменения, которое может быть сделано с версии 1 на версию 1.1:

Версия 1: Имя человекафамилия

Версия 1.1 Персона Имя Фамилия Дата рождения

Если вы получаете доступ к API с версией 1.0, вы не получаете атрибут рождения - он доступен только в версии 1.1.Мне нужна инструментальная поддержка для предоставления этих сервисов, где я могу настроить, что при условии, что мое pojo (которое в настоящее время похоже на версию 1.1), я хочу сделать доступной версию 1.0, которая не показывает эти значения.

Другие юридические изменения в модели могут заключаться в том, чтобы удалить атрибут или переименовать атрибут (или даже переименовать объект).

Редактировать 2: Цифровой Джоэл упоминается в комментарии, что для обсуждения о версии API вы должныперейти к чтению https://stackoverflow.com/posts/9789756/.

Самый простой выход из управления версиями - это, конечно, не вносить назад непоправимые изменения API, а изменить бизнес, так что это не всегда возможно.Меня интересует, как сделать эти изменения более простыми в обращении, поэтому мой вопрос.

Редактировать 3: Я искал инструменты, которые могли бы помочь процессу, но все же ничего, что бы хорошо связывало это с отдыхом,Вот ссылки, которые я нашел до сих пор:

• http://wiki.pmease.com/display/xmt/What%27s+XMT (похоже на библиотеку для помощи с сериализацией pojos в xml с контролем версий)

Answer 1

Как уже упоминалось в одном ответе, может не быть доступных инструментов, для которых выполняется автоматическое управление версиями API.

Мы можем решить эту проблему с помощью двухэтапного подхода:

1) Информация о версии API Есть много споров о передовой практике. Два самых популярных:

(i) URI redesign - putting version info in URI like
http://something.com/v1.0/resource1/ or
http://something.com/resource1?ver=1.0

(ii) Using HTTP Header - putting version info in Accept/Content-Type
header keeping URI intact like 
#
GET /something/ HTTP/1.1 
Accept: application/resource1-v1.0+json

2) Несколько версий одного и того же pojo с использованием библиотеки json / xml

Как только информация о версии будет у нас, мы должны соответствующим образом сгенерировать ресурс. Существует множество библиотек json и xml, с помощью которых мы можем поддерживать несколько версий одного и того же pojo и сериализовать только необходимые атрибуты в зависимости от версии. Google GSON Java-библиотека прекрасно работает в этом. Проверьте https://sites.google.com/site/gson/gson-user-guide#TOC-Versioning-Support

public class Person{

@Since(1.0)
private String firstname;

@Since(1.0)
private String lastname;

@Since(1.1)
private String birthdate;

}

Answer 2

Это не тот ответ, который вы, возможно, ожидаете, поскольку я не использую внешний инструмент с открытым исходным кодом, чтобы сделать тяжелую работу за меня. Я использую свой собственный инструмент.

Я использую Джерси. Я использую / vx /, включенный в мои объявления @Path.

Поскольку REST apis представляют контракты, я не доверяю автоматическому созданию. Тем не менее, я создал инструмент XLST в не очень сложном плагине maven.) Я поддерживаю сжатую версию xml и превращаю ее в класс Jersey в gensrc.

Я обнаружил, что v1 имеет определенный путь и параметры матрицы / запроса, уникальные для проекта в то время. Когда я разрабатываю v2, я часто обнаруживаю, что мне нужно поддерживать дополнительные параметры или реструктурировать свои URL для лучшего понимания. Мне просто нужно изменить XML-файл.

Мой механизм генерации создаст слой из Джерси с MyAPIv1.java и MyAPIv2.java и аннотирует в соответствии с необходимостью времени.

Так что я хочу сохранить контроль над версиями, и использование авто / инструмента может быть вредным.

Опять же, использование спецификации - отличный способ полностью контролировать, но не полностью реализовывать тонкие слои.

Так что здесь нет сигары, но это может быть полезно.

Answer 3

Мне не известны какие-либо инструменты для автоматического создания версий вашего RESTful API. Для большой дискуссии о версии REST вы должны прочитать Рекомендации по управлению версиями API? .

Я потратил немало времени, изучая это при планировании API RESTful, и мы пришли к выводу, что мы будем развиваться так, чтобы не вносить существенных изменений. Если требуется срочное изменение, мы бы представили его как новый ресурс, а не пытались использовать информацию о версии в пользовательском заголовке или типе mime. Но, на ваш вопрос, это означает работу на моей стороне, что еще более стимулирует не делать кардинальных изменений.

Когда дело доходит до инструментов, я серьезно сомневаюсь, что вы найдете что-то, что может автоматически вносить изменения, необходимые для поддержки нескольких версий вашего RESTful API. Для этого потребуется инструмент, который понимает различия между двумя версиями вашей модели и всеми взаимодействиями в вашем API.

Если вы соответствуете принципу REST HATEOAS, тогда все ответы из заданного местоположения также включаются в ответ, и в этом случае вы можете использовать что-то вроде REST для поддержки отображений запросов в Spring MVC, чтобы сохранить номер версии в все ваши URL-адреса имеют единую точку входа от клиента, но вам все равно потребуется поддерживать контроллеры и модель для каждой версии.

Answer 4

просто мысль, но разве не было бы лучше сделать ваш API обратно совместимым;тогда вам нужно только управление версиями для вашего хранилища кода, и это намного меньше хлопот?

Answer 5

Вы говорите о чем-то, что собирается сделать это для вас в мире разработки (поддержание версий вашего API для предоставления пользователям) или в мире живых серверов (согласование контента во время выполнения)?

Для первого взгляните на такие инструменты, как maven, ivy, gradle ... вот для чего они нужны. Я лично использую maven, потому что это тот, который я знаю лучше всего, но все они позволяют вам публиковать файлы jar с версиями именно для этой цели.