Добрый день, подскажите, существуют ли у ws какие-то весомые преимущества над hs и считается ли ws устаревшей практикой при разработке новых интеграций?

Ws в ряде случаев удобно делать при интеграции 1с-1с.
http - удобно для интеграций вида 1с-внешняя система.
Никто не запрещает и для 1с-1с делать http.

Я бы смотрел в сторону http.

кроме типизации из коробки?
нету

+1 Весомых преимуществ не вижу.

веб-сервисы - это же некомильфо уже.
схема эта больше мозги насилует, чем помогает, REST более гибкий, именно поэтому 99% интеграций - REST.

(2) этого мало?

(5) мало
потому что еще не видел ws где в конце концов не извратились
и тупо тип сделали строка, куда засовывают что угодно через сериализацию
для гибкости

ну или извраты с кучей свойств разных типов у одного объекта - чтобы реализовать аля составной тип

(6) +100500

(6) истина случается

Одинесники привыкли жить в нетипизированном мире, чтобы навалить в одно поле всякого 💩.
А потом им с типами "неудобно"

(0) ws жестко типизирован, ты не сможешь передать туда что-то лишнего или подсунуть какие-то данные в другом формате. Если там сказано, что после запятой 1 знак, то 2 знака ты туда не подставишь, придется менять схему.
Если нужна доработка в схеме-xml, то ее надо менять одновременно с двух сторон.
Для ws платформа сама сгенерирует подробную ошибку, если в коде произошла исключительная ошибка, на другой стороне увидят ее описание (код http-ошибки и текст, который сгенерировала платформа).

Rest более гибкий формат, нет строгой типизации. Это и хорошо и плохо. Если надо сделать доработку и добавить какое-то новое поле в выгрузку, то ее необязательно делать сразу с двух сторон, можно добавить ее на стороне выгрузки, а на стороне приемки сделать доработку по обработке этого поля чуть позже. Ошибок при этом не будет.

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

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

(6) я через свой первый WS лет 10 назад гонял ТЗ - через устаревшие методы ЗначениеВСтрокуВнутр и обратно разбирал и получал ТЗ )) Давно не использую WS, проще самому все сериализовать

(12) У этого метода ограничение есть по объему данных :)
Я как-то напоролся

Не очень приятная особенность web - медленное подключение.

Для меня есть только один вариант обмена — HTTP. Всё остальное дольше, сложнее, ненужнее, неуниверсальнее и т. д. Только после того как я узнал про HTTP, я смог отказаться от монолитной базы.

1. типизация в WS - это иллюзия.
на моей практике:
либо схема превращается в <xs:any>, чтобы запихнуть что угодно, либо ее постоянно ломают 'расширениями', превращая в spaghetti из optional-полей.

REST + JSON Schema / OpenAPI даёт гибкость без потери контроля. а если нужна строгая валидация - никто не мешает добавить ее на уровне middleware.

2. WS убивает скорость разработки:
любое изменение схемы требует синхронного обновления обеих сторон.

3. ошибки валидации часто непонятные и требуют копания в WSDL.
REST позволяет:
постепенно наращивать API (backward compatibility).
использовать готовые инструменты (Swagger, Postman).
легко масштабироваться с помощью версионирования.

3. про перформанс:
WS медленнее не только из-за XML, но и из-за накладных расходов на SOAP-обертки.
если у кого-то 'медленное подключение' - это проблема не протокола, а архитектуры.

WS - это legacy даже не в мире 1С.
вне экосистемы 1С его почти не используют.
HTTP - это стандарт де-факто:
поддерживается всеми языками и платформами.
легко интегрируется с облаками (API Gateway, serverless).
позволяет использовать современные практики (JWT, OAuth2, GraphQL).
зачем изобретать велосипед, если весь мир давно выбрал HTTP?
WS удобно для 1С-1С?
ну да, только если вы застряли в 2005 году.

(0) О, одна из тем моего последнего доклада на Инфостарте.
Если кратко: для взаимодействия с внешними системами - http, для взаимодействия 1С<->1С - web.

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

Поддержу (1) и (17) внешние - http, 1С-1С (в т.ч. мобильное приложение) - ws.

(19) ааа динозавры атакуют...

имхо применение xml и ws сейчас допустимо только в легаси проектах
где это исторически сложилось и иначе ну никак

во всех новых только json и hs

(20)+ ну не используют сейчас математики римские цифры в расчетах при обычной работе!
только арабские - вот такая аналогия

(20) Есть моменты, когда xml при обмене 1С-1С работает корректнее. Один и тот же алгоритм: сериализация в xml - работает, сериализация в json - ошибки.

(22) можно примеры?
с датами не учитываем там все решаемо

(22)
эмм какой еще алгоритм?

я про встроенную типовую сериализацию в json речь веду так то
https://wonderland.v8.1c.ru/blog/serializatsiya-prikladnykh-tipov-1s-predpriyatiya-v-json/?sphrase_id=1363428

если не хватает то ручная через структуры
https://wonderland.v8.1c.ru/blog/sredstva-raboty-s-json/

(20) видимо нравится людям страдать.

(0)

(16)
"WS - это legacy даже не в мире 1С.
вне экосистемы 1С его почти не используют."

Якубович: Да ладно)
У меня в проектах какие были не из мира 1С: РЖД Этран, Меркурий, SAP PI, GS1 (описание товаров и регистрация GTIN). До сих пор живы.

Имелось в виду новые проекты интеграции на нем не запускают?

WS — для очень серъёзных обменов с очень серъёзными организациями, для которых громоздкость, костность и сложность технологий — преимущество (меньше вероятности пострадать от мамкиных хацкеров и недоученных фронтендеров)

REST — для всех остальных

(27) В корпоративном секторе (особенно в госструктурах и крупных предприятиях) SOAP ещё живет - просто потому, что переводить legacy-системы на новые протоколы долго и дорого. Ваши примеры как раз это подтверждают. Новые проекты на SOAP будут писать разве что некрофилы.

(10) >>EnterpriseData

Лет 8-9 назад, когда переводил 2.0 БП на 3.0, возникла необходимость обмена с движениями. Пришлось делать свою приблуду на правилах xml.

2025 год, франчи внедряют бит финансстроительство, и оп, как будем делать обмен из общей базы в перефирийки? Угадайте с 3 раз)))

Внимание вопрос, нахрен было убирать xml, если EnterpriseData все равно в темпы файлики пишет?

WS — это медленно и геморройно. Не использую сейчас уже никогда.

HTTP — однозначно всегда!

веб ориентирован на результат, хттп на скорость
и да - какая разница как строку совать ;P

(5) это плохо, надо синхронно типы поддерживать

(9) ну так в этом и суть, платформа не типизирована. WS типизированы....ничего не замечаешь?

Одинаково.