Вопрос про формат запроса

А не про  "Grasp, data hiding, инкапсуляция, анемичная модель."

Это известно

Вопрос был такой?  - Это норм?

Переформулирую :)

Вот такой формат запроса по API для изменения данных в объекте:

Сам запрос:

{
  id:42,
  columns: {
    "address": "Russia, Voronezh",
    "name": {
      "firstName": "Ivan",
      "lastName": "Petrov",
    },
  },
}

Норм?

{
  id:42,
  columns: {
    "address": "Russia, Voronezh",
    "name": {
      "firstName": "Ivan",
      "lastName": "Petrov",
    },
  },
}

Ну я бы убрал columns. И норм)

Дальше я так понял война между теми, кто говорит, что логика внутри объекта должна быть и теми, кто говорит, что не должна

С таким подходом тебя должно поставить в ступор от того что graphql побеждает, и что RESTfull предполагает что ресурсы передают семантику.

И от того что делая плоский dto ты идешь против природы RESTfull

природа RESTful это гипертекст

а то что ты называешь rest это json rpc over http

и он не плоский

Ну мы же можем не показывать реальную структуру базы. А придумать доп уровень.

плоскость и "дублировать структуру базы" это разные вещи. Посмотри на graphql как хороший пример. Красиво ложится на всякие соц сети и прочие гитхабы

вот, да, я об этом, а про json rpc over http это все я знаю, я как раз не про него)

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

если у тебя на UI компоненты типа

Пост
  - описание
  - количество комментов
  - тэги

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

Не знаешь как правильно возьми юайщика и он скажет как ему удобно

ведь это тупо делать плоскую структуру которую потом надо на клиенте нормализовывать

а если еще ORM на сервере юзать то это ж восхитительно. Достали из базы - замэпили. Потом замэпили на dto. потом надо еще раз мэпить на другие структуры... и каждый этап шот может пойти не так.

А так вжух вжух структурки попроще и сам будь попроще и проще будет за контрактами следить

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

BFF мне нравится так чта