• Які є конвенції в REST API та для чого їх дотримуватись

    Думаю это будет более наглядно.
    play.golang.org/p/-8vHycUBflq

    Опять же. В Go все свелось к тому что там примитивы и дефолтные значения что (как по мне) только усугубляют эту проблему т. к.

    {}
    { «code»: null ... }
    { «code»: 0 ... }
    { «code»: 999 ... }

    В Java будет
    public class TestClass { Integer code; }
    null, null, 0, 999

    в GO будет
    type Data struct { Code int `json:"code"}
    0, 0, 0, 999

    Но думаю что это больше философия языка и подход про который нужно больше почитать чтобы понять как оно вообще тогда с БД работает.

    Думаю ответ в плане, в GO это решено закрыт.

    Поддержал: schwarzlichtbezirk
  • Які є конвенції в REST API та для чого їх дотримуватись

    Зачем нам удалять с модели поле?

    Потому что PATCH это частичный апдейт где вся идея в том, что в переданном JSON нету некоторых полей.

    Поля с null можно и не отдавать клиенту, считая что их и нет в модели.

    Вопрос не про запись, а чтение json.

    body json схему, то удалим не саму модель, а указанные поля.

    т. е. Delete /card/1 {address: null} должно модифицировать 1 поле ? С body в Delete и так хватает проблем, а тут мы еще не удаляем ресурс а модифицируем его. stackoverflow.com/...​or-an-http-delete-request

    Кажется неправильным использовать Delete для такого так как он должен удалять весь ресурс.

    Ну видать это грабли конкретной реализации парсера в строго типизированном ЯП. Без понятия что там за такой парсер, что предоставляет API который не различает отсутствие поля и поле с null.

    Так в этом и смысл что это не парсер, а то в то что он парсит.
    Опять же пример.
    {}
    { «code»: null ... }
    { «code»: 0 ... }
    { «code»: 999 ... }

    В Java будет
    public class TestClass { Integer code; }
    null, null, 0, 999

    в GO будет
    type Data struct { Code int `json:"code"}
    0, 0, 0, 999

  • Які є конвенції в REST API та для чого їх дотримуватись

    Ну вот вы говорите про запись в json, а я про чтение.
    Как я понимаю в Go должно быть что то наподобие *Integer и тогда мы получим ту же проблему что и в Java. Мне не нужно создать json мне нужно его обработать.
    (Забыл про главный use case когда {} = ничего не меняем)

    Просто вы приводите пример (и судя по коду так заведено в Go) с использованием примитивов которые не могут содержать null, и имеет всегда состояние со значением что ещё больше (по моему мнению) связывает руки. И добавляет вопрос Как понять что у юзера на счету 0 грн или он ещё даже не имеет счета.

    Но думаю это разговор уже совсем другого топика, и если

    элементарно

    сводится к использованию встроенных дефолтных значений то нужно понимать что это не совсем полное решение а больше как ограничение

    Поддержал: Dmitry Bugay
  • Які є конвенції в REST API та для чого їх дотримуватись

    PATCH только для изменения значения полей,

    А чем выставления 1 поля в модели (ресурсе) как null не изменение ?

    Зачем нам удалять address? Есть ресурс, есть его схема, зачем удалять от туда что то, вместо сброса в null? Очень ли важно различать отсутствие поля в модели от его наличия с null?

    Ну опять же. Как я понимаю, если у нас есть 9999^9999 инпутов то придут Frontend devs и попросят Patch сделать. А сохранять в бд отсутствие параметров как пустые строки или 0 кажется неправильным подходом.

    Да и если что в DELETE как бы не запрещено body передавать.

    Хм. В REST мы же работает с ресурсами. И если мы вызываем DELETE /card/1 то (я думаю) мы ожидаем что этот ресурс удалится и плевать какое body.
    Можете объяснить что вы хотели сказать ?

    то приняв простое соглашение, что null равнозначен отсутствию поля, проблема решается сама собой.

    Ну так смысл вопроса в том что при работе с моделями бэк и не может понять нам передали null или нет. (без костылей аля препроцессим json руками) И тут нужно идти дальше и говорить что мы теперь не поддерживаем null вообще и пускай используют PUT если юзер что то удалил что напрочь убивает смысл PATCH и его удобство для Frontend devs. (если конечно мы не используем дефолтные параметры везде и бд у нас с null а не с 0 и пустыми строками)

    Поддержали: Oleg Zinoviev, Dmitry Bugay
  • Які є конвенції в REST API та для чого їх дотримуватись

    Хм. А можете привести пример где эта проблема явно решена. Именно код модельки с которой можно понять
    { «code»: null ... } - тут нужно выставить code в null (нам важно знать что он именно отсутствует)
    { «code»: 0 ... } - тут нужно выставить code в 0 (валидное число от юзера)
    { «code»: 999 ... } - тут нужно выставить code в 999 (валидное число от юзера).

    И как с моделькой дальше можно работать без костылей

  • Які є конвенції в REST API та для чого їх дотримуватись

    Как у вас решили данную проблему ?

  • Які є конвенції в REST API та для чого їх дотримуватись

    Я вижу что там используют зачастую примитивы и у них конечно есть дефолтное значение. Если в Java использовать тот же подход то мы получим тот же объект на выходе с дефолтными 0, 0.0 (а для String можно явно задать дефолт "")

    И я не понимаю где

    Это же элементарно

    . Вы сами говорите что у вас

    это поле будет записано в json, если оно пустое/нулевое.

    . Именно что пустое оно или нулевое как раз в PATCH имеет значение.

    Разница между null и дефолтным 0 же огромная...

  • Які є конвенції в REST API та для чого їх дотримуватись

    А можно его как то тегнуть ? или как я его могу найти ?

  • Які є конвенції в REST API та для чого їх дотримуватись

    То что PATCH ооооочень нравится Frontend devs это понятно, а хоть кто то реализовывал PATCH в реальных проектах?

    (Возьмем JAVA)
    Вот во многих статьях забывают что используя объекты мы можем иметь по сути 2 состояния.
    — Значение (или дефолт значение)
    — Null

    Но вот в чем проблема. Как нам понять что человек передал нам null или просто не передал нам поля и он не ожидает что поле очистится.
    {  "id": 1,  "address": null  }
    ==
    {  "id": 1 }

    Т. Е. у нас на выходе и так и так будет объект с address null и потом мы никак не определим что именно мы получили.
    Лучшее что находил это вот эту статью (во многих других как будто все игнорируют эту проблему...)
    nullbeans.com/...​ing-a-rest-api-in-spring

    (Приходила идея получить заветное 3 состояние с помощью Optional, но вроде наркомания немного)

  • Навіщо використовують DTO. Приклади в Java-застосунках

    Да интересный подход, и так мы можем оперировать на уровне реализации «полным» entity а наружу будет виден только нужный интерфейс модели.
    Конечно хочу попробовать сначала, потому что с наследованием нужно быть осторожным, а тут еще наследование моделей, с которым легко упороться.

    У вас не росла сложность и количество боли при менеджменте наследования modelApi->modelImpl после такого подхода ? потому что не приходилось работать с командой над системой в который большой слой именно контроллеров.

  • Навіщо використовують DTO. Приклади в Java-застосунках

    Та тут просто хотел получить структурированный ответ на практическую проблему.
    А «хуяк-хуяк и в продакшн» всегда можно сделать.

  • Навіщо використовують DTO. Приклади в Java-застосунках

    Да, звучит логично. Воспринимал DTO как единственную возможность общения между слоями контролера и сервиса. Но тогда возникали проблемы что использование сервиса в других сервисах начинает быть неудобным, потому что иногда нужно именно Entity а не DTO, хотя с другой стороны это делает их более независимыми.
    Нужно где то попробовать будет такой подход в контролерах и посмотреть насколько решит эту проблему + какие будут новые, не встречал пока что подобного в коде, везде маперы суют в сервисы.

  • Навіщо використовують DTO. Приклади в Java-застосунках

    Ну тогда контроллер будет получать Entity объекты про которые он вообще не должен знать. Я более склонялся к еще 1 прослойке между ними, но нигде этого не видел и возможно это уже over engineering

  • Навіщо використовують DTO. Приклади в Java-застосунках

    Ну это понятно. Просто если у нас DTO класс и должен быть с внутренними объектами, мапстракт сам полезет и начнет их мапить (если ему явно не указать чтобы он их не трогал). И мы получим N SQL запросов если забыли join fetch

  • Навіщо використовують DTO. Приклади в Java-застосунках

    Ну т.е. в Spring не писать @Transactional а юзать TransactionTemplate и самому оборачивать. Думаю такое не очень удобно. Где тогда должен быть маппинг, в отдельном классе выше *Service ?

  • Навіщо використовують DTO. Приклади в Java-застосунках

    Хорошая вводная статья.
    Но на практике при большой вложенности объекта Entity и если не следить за сгенерированным Mapstruct кодом можно легко как раз и нарваться на N+1 проблему. Например mapstruct зайдет сам в каждый вложенный объект и сам попробует его конвертировать. Как правило Марино находиться в сервисе = в транзакции и мы получим огромное количество запросов если до этого не сделали join fetch.
    При использовании «удобных» библиотек можно откопать те же проблемы только под другим углом.

    Поддержал: Sergiy Morenets