Java переопределить классы с несколькими конструкторами против нескольких классов

Question

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

Например, у моего пользовательского класса есть атрибуты, такие как id, balance, name.Когда я создаю нового пользователя, отправляя запрос POST, такие атрибуты, как id и balance не нужны.

Это подводит меня к вопросу:

• Должен ли я отправлять другой объект (подобно UserCreate, имеет только обязательные атрибуты для создания нового пользователя) для API и получения полного объекта User?

ИЛИ

• Должен ли я добавить еще один конструктор для моего пользователяобъект, который требует только все обязательные параметры (имя)?

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

(Другой подход мог бы заключаться в работе с Object (), но каким-то образом это не сработало (Express говорит, что это http 400).Возможно ли в retrofit2 отправлять любые объекты в запросе Post?)

Answer 1

Во-первых, ваше Java-приложение должно учитывать все необходимые операции, такие как CREATE, UPDATE, DELETE.Они - примерно - идентифицированы с помощью HTTP-методов PUT, PATCH & DELETE соответственно.

Теперь представление DTO, которое ваш внешний интерфейс отправляет (JSON / XML / REST) ​​в бэкэнд Java, может быть таким же вкаждый случай: СОЗДАТЬ, ОБНОВИТЬ И УДАЛИТЬ.Ваш бэкэнд должен реализовать вышеупомянутую функциональность для методов HTTP, перечисленных выше. DTO (возможно, с именем UserDTO), который вы отправляете из внешнего интерфейса в внутренний, может быть одинаковым во всех случаях.В этом DTO вы можете просто оставить все несвязанные (не связанные с операцией) поля неустановленными / пустыми.

Более подробно: в вашем бэкэнде должны быть методы, принимающие методы HTTP:

• PUT где DTO имеет все остальные необходимые поля, но Id
• PATCH, где DTO имеет поле Id и все измененные поля
• DELETE, где DTO имеет только Id

Я не знаю, как используемые вами структуры создают фактический POJO из отправляемого вами DTO.Но теперь у вас есть эти три метода, в которых вы действительно знаете, как обрабатывать входящий DTO, т.е. вы знаете, является ли он CREATE, UPDATE или DELETE.

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

, но что, если публикацияпотребуется набор совершенно разных атрибутов?(атрибуты, которые не включены в мой класс пользователя)?

Это похоже на HTTP POST.Так что это не операция CREATE, UPDATE или DELETE, а что-то, что изменяет состояние - возможно, пользователя - на основе какой-то произвольной операции и данных.Конечно, для данных, не принадлежащих Пользователю, вам нужен другой DTO для хранения этих данных.