Друзья!
Я начал изучать web сервис. И прохожу курс по обмену, в котором показывается, что обмениваться через web сервис можно с помощью XDTO-пакетов, для этого необходимо создать схему этого XDTO-пакета. Однако, я увидел на просторах интернета, как будто гораздо более простой способ: Выгружаем результат запроса в таблицу, ее кладем в Структуру с одним параметром, например "ТЗ", и далее серелизуем и передаем через web сервис. Тут не нужно пилить новые XDTO-пакеты.
Так какой способ наиболее хорош? Я еще не практиковал на рабочих задачах и не знаю.

(0) Если метод хороший - он универсальный! (с) Том Сойер

(2) совсем не факт.
обратное - стопудово!

(0) В случае с формализованного XDTO пакета ты не греешь голову, что тебе передали. Формальная проверка на соответствие проходит в момент передачи.
Если бы я делал API для внешних клиентов - я бы использовал формализацию, чтобы избавить себя от лишнего геморроя по проверке. Если бы делал внутренний сервис - то пошел бы по пути меньшей формализации, чтобы не переделывать сервис при на каждом изменении в период бурного развития функционала.

(4) После 4 лет бурной работы с сервисами.
Если вы приходящий сотрудник, то абсолютно с Вами согласен.
Если Вы постоянный сотрудник - "то пошел бы по пути НАИБОЛЬШЕЙ формализации процесса"👍

Есть тонкости(заложенные бомбы)
https://blog.sikuda.ru/?p=3169

(0) проще сразу уйти на HTTP сервисы. Web сервисы слишком не быстрые и излишне сложные. Гуглишь и качаешь модуль КоннекторHTTP и в целом ни каких сложностей для общения с сервисами не будет.
Но не забывать писать описание и примеры в том же open api. А для тех же внешних сервисов, можно проводить валидацию каждого пакета и выдавать читаемые ошибки. Примеры валидаторов гуглятся на раз два.
А костыли это зло. Вот в данном примере придет другой человек и у него будет море вопросов,. зачем тут веб сервис, что за сложная структура, это требования к внешней интеграции или кривой код...

(5) Что можно 4 года с сервисами делать? Вы их на Сахалин возите в нартах? Тогда лучше максимально причесать чтобы по снегу сопротивление было ниже.
Всегда восхищался людьми, умеющими тянуть коня за хобот годами. А то только напишешь один два сервиса и "все, спасибо. Нам больше не надо. Вы уволены."
(6) Посмотрит другой человек - и уйдет. Если умеешь изгадить на века - место в компании твое. Ибо платить за переделку никто не будет, а деньги получил тот, который все это написал.

(7) https://habr.com/ru/articles/670700/

(8) осторожно, графомания

(6) Абсолютно согласен. Тут еще на днях выяснилось, что WEB сервисы начинают на порядок медленнее работать после перехода на платформу 8.3.27.1719 при запущенном конфигураторе в режиме отладки по http (никаких автоподключений нет, конфигуратор закрываешь - все норм).

(9) фактические данные









только не сережа, а саша

млааа кровь и слезы(((

(11) ебануться!

(11) ништяк, гипотетически если сотрудников миллион +(может даже при 100тыс+ будет интересно так хранить), а история хранится за 10 лет, плюс распределенка, то это вполне оправдано.
В целом колонки можно не создавать вручную, а кодом создать.
Но я бы кнчн выбрал тот же кликхаус для хранения данных, а перед этим покрутил обновление и чтение данных за год штатными средствами без такого ужаса.

(12) я понимаю, что бывает и круче, но это тоже неплохой вариант, может пободаться с аналогичными по своей л - логике
(13) что ништяк, то ништяк! про оправданность только не понял