спасибо

да ты что, там же норм пикча, сначала типо огромный биток, а в конце пара сатоши

Нет. Это набор хаков как полуяить юолее менее хэш специфик юраузера и устройства. Нет там никакого поведения

Привет, что-то я подзапутался. Есть сервис по созданию, просмотру и редактированию ордера. Первый запрос достает все ордеры, список в котором должна быть краткая инфа. Второй запрос достает полный ордер для отображения. Третий запрос - пошаговое создание этого ордера, состоящее из нескольких экранов/шагов. Сервис rest но в банальном его понимании, тупо обмен json ками. Не могу уложить как лучше формировать DTOшки.
На первый запрос просто  /orders вернёт лист из простых DTO  в которых айди и пара полей для отображения(название, дата, статус).
На второй запрос orders/{orderId}  уже проблема что вернуть. Так как ордер очень сложный объект, внутри которого есть другие сложные объекты, я не понимаю как построить иерархию DTO. Такой же набор классов с такими же полями как и у domain order  или же что-то урезанное и простое? Потому что если урезанное и простое, то на этап создания, придется все равно создавать ещё один DTO  уже отличный от того который на получение

Другими словами лучше возвращать OrderDetailsDto внутри которого часть полей ордера, часть доп полей и ТД. Или просто OrderDto

Неужели в вашем случае редактируется и просматривается всегда весь набор данных?

Практически. Сейчас клиент на gwt и работает с теми же объектами что и сервер. При входе в режим редактирования, все поля становятся  editable

На клиент сейчас возвращается полный ордер, со всем данными

Вот по другому ещё. Есть три поля  в ордере. creationDate, status, gender. Просто для примера. И сейчас на клиенте gwt может высчитывается что-то типо boolean hasDiscaunt. Не понятно как лучше, вернуть новому клиенту на реакте все три поля и пусть сам считает из них hasDiscaunt. Или добавить в DTO поле hasDiscaunt и вернуть уже высчитаное клиенту

Высчитанное клиенту лучше, чтоб бизнес логика не утекала на фронт.

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

Да. Но сейчас это на стороне клиента gwt  делается

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

Второй вариант надежней. Позволит поменять правила без изменения фронтенда.

Разделяйте Read и Write.

Чтоб не описывать одинаковые поля, то можно трейт/миксин сделать(чтоб не плодить вложенности), ну или как вы предложили с Details - тож норм.

Тоесть клиент запросил ордер. Отрисовал его. Нажали редактировать. Клиент должен сформировать новую дтошку и отправить на сервер для обновления?

Или же ту же что и получил все таки?

В обратную сторону на сервер ведь имеет смысл только невиртуальные/невычислимые данные отдавать.

GET: отдает Order+OrderDetails
POST/PUT: принимает Order

Ещё вопрос, стоит ли писать enum DTO?