Я строю REST API, чтобы показать большую часть функциональности существующего Java API. Оба API предназначены для внутреннего использования в моей организации; Я не должен проектировать для внешнего использования. Я имею влияние на оба API, но я использую REST. Java API будет по-прежнему использоваться для локальных приложений (он не «удаляется»), но REST API будет использоваться для значительных новых разработок.
Некоторые из классов Java API - это просто данные (бины со свойствами, геттеры, сеттеры). И, по крайней мере, некоторые из них имеют смысл передавать (в некоторой форме) через REST API в виде данных (которые будут перенаправлены в XML или JSON). Например, класс, в котором хранится информация о сервере. Я столкнулся со следующим выбором для этих классов данных: я ...
- предоставить исходный класс Java (или подкласс) непосредственно в REST API, или
- сделать новый класс передачи данных (шаблон DTO) специально для REST API?
В любом случае у меня будут классы передачи данных REST; вопрос заключается в том, нужно ли комментировать оригиналы или создавать новые (которые могут быть рядом с копиями оригиналов). Могут быть и другие варианты, но я сосредоточусь в основном на этих двух.
Аргументы за № 1:
- СУХОЙ (не повторяйся)
- Быстрее реализовать
- Проще обновить REST API
Аргументы за № 2:
- Что делать, если REST API должен быть версии отдельно от Java API? (Это несколько вероятно.)
- Что, если в классы данных Java будут внесены значительные изменения, такие как удаление свойств, добавление поведения или изменения в иерархию классов? (Это также несколько вероятно.)
Суть в том, что это похоже на компромисс между СУХОЙ (# 1) и развязкой (# 2).
Я склоняюсь к тому, чтобы начать с № 1, а затем, если возникнут проблемы, переместиться на № 2 позже, следуя гибкому руководству: не строить то, что вы не можете доказать, что вам нужно. Это плохая идея; Должен ли я начать с № 2, если я думаю, что я могу оказаться там в любом случае?
В моих списках отсутствуют основные аргументы / последствия?