Как нужно возвращать структуру веб-сервисом? #791773

Создаем веб-сервис с пакетом . В операции у возвращаемого значения тип указываем Structure. Фактически в операции возвращаем значение СериализаторXDTO.ЗаписатьXDTO(Новый Массив). И все проходит без ошибок. Почему так? Это корректное поведение? Как нужно организовывать веб-сервис, чтобы возвращать тот или иной тип?

ошибка будет на вызывающей стороне (если это 1с)

не будет, я проверял

вызывающая сторона кто?

1с

результат = Прокси.Метод и результат прям массив?

результат типа ОбъектXDTO после выполнения СериализаторXDTO.ПрочитатьXDTO(ОбъектXDTO1) получается массив платформа 8.3.9.1850

демонически обновлял?

был он когда-то массивом?

да, нет чистую базу создал могу прикрепить сюда

прикрепи к письму в техподдержку 1с. у нас тут только психологическая поддержка.

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

я напишу в 1с, да интересно и тут перетереть

веб сервисами пользуюсь, но никогда не заморачивался с типами - мне тупо нужен был всегда JSON массив, а с ним проблем нет он тупо передается как строка

почему именно JSON массив?

с ним легко работать

потому что кое-кто путает http и web сервисы

нифига я не путаю

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

чем именно JSON легче чем xml сериализация?

ээ.. не одобряешь что именно?

вот запрос к веб-сервису   а вот ответ

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

это хттп сервис

мне на стороне сайта с ним легче работать, а объяснять долго

это веб-сервис спорим?

ты вызываешь php, как ты в пхп крутишь данные - мне неизвестно. объекты XDTO на стороне php преобразуются в объекты php, при указании класса - еще и с методами. то, что ты делаешь - можно сделать и без лишней прослойки из php.

только http сервисами

можно, но сделано как сделано, увы

да и вызывается не php как таковой, а юзается его SOAP-Client

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

как раз из-за того, что в js нету своего соап клиента. так вот, без прослойки это можно сделать на http сервисах 1с и будет работать быстрее (и сам вызов http сервиса и отсутствие прослойки)

совет давно понятен, но работает - не трожь со временем перепишем

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

а где я претендовал на правильность?

в

может еще раз перечитать ?

при формировании своего пакета (xsd схемы) мы прибиваем гвоздями структуру данных, при использовании Массива, json и прочего - мы "договариваемся" о структуре данных. и тогда получается, что при расширении структуры начальная документация, даже если и была - становится не актуальной, а на актуализацию все забивают. А в случае жесткой схемы - мы вынуждены её модифицировать, получая самодокументируемость.

+ конечно, неполную, но лучше, чем ничего

я прочитал как "забей на схемы, используй строку с json"

ну так это же не мои проблемы )))

ты имеешь ввиду, что всегда при использовании непримитивных типов нужно делать свой XDTO-пакет в дереве метаданных и его указывать в веб-сервисе? чтобы клиент мог через фабрику читать xdto-пакеты?

что-то типа того. для сервисов, предназначенных для одинаковых конфигураций объекты конфигурации можно юзать из current-config, но всякие структуры - да, прибивать гвоздями в пакете с именами и типами свойств.

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

именно так! самодокументируемость - то, что не надо глядеть в код для получения состава передаваемой информации. То, что клиент (в которого загружен пакет) понимает, что что-то на сервере изменилось, и, возможно, надо менять алгоритмы взаимодействия. Ну, по крайней мере, произвести их инспекцию и задать вопросы разработчикам серверной стороны.

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

версионность нужна, да. независимо от того, прибиваем, или нет, гвоздями.

У клиента должна быть xsd схема, для десериализации объекта. Если xml пришедший из web- сервиса не проходит проверку схемой, то значит изменилась схема на сервере и необходимо об этом оповестить клиента.

А не поздно ли оповещать клиента, если xml уже не прошел проверку на клиенте?

1с сказала - так и нужно. ошибки нет