Создаем веб-сервис с пакетом http://v8.1c.ru/8.1/data/core.
В операции у возвращаемого значения тип указываем Structure.
Фактически в операции возвращаем значение
СериализаторXDTO.ЗаписатьXDTO(Новый Массив).

И все проходит без ошибок. Почему так? Это корректное поведение?
Как нужно организовывать веб-сервис, чтобы возвращать тот или иной тип?

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

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

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

1с

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

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

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

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

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

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

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

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

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

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

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

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

(16) нифига я не путаю

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

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

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

(16) вот запрос к веб-сервису  http://SSMaker.ru/8a0eedd0/

а вот ответ  http://SSMaker.ru/feab8bac/

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

(21) это хттп сервис

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

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

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

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

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

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

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

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

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

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

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

(34) в (13)

(35) может еще раз перечитать (13)?

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

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

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

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

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

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

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

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

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

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

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

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

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