REST интерфейс для 1С #692749


#0 by bazvan
Вот они чего наделали веб расширение хоронят
#1 by Fragster
вебрасширение и так не нужно было
#2 by dj_serega
а как же "тыкать" по кнопочкам в 1с? ых...
#3 by mikecool
и пусть хоронят, если есть что то более новое и лучшее
#4 by Fragster
вообще круть
#5 by Fragster
еще бы json прикрутили
#6 by dj_serega
вот оно че (может кто не дочитает =) ): Поэтому развитие и поддержку web-расширения мы планируем прекратить.
#7 by Fragster
а ты его юзал?
#8 by Fragster
+ я ни одного человека не знаю, кто бы юзал.
#9 by dj_serega
я разрабатывал :) а юзали пользователи :) как по мне лучше бы и REST и web развивали дальше. Не хочу ничего стороннего покупать/устанавливать если нужно с web-а в 1С достучаться.
#10 by Волшебник
веб-сервер по-любому нужен
#11 by dj_serega
а Web-расширение жалко.
#12 by Fragster
дык соап же. в тренде json (по крайней мере, безгеморно в обе стороны). А тут какая-то заляпуха, позволяющая напрямую изменять данные в 1ске вместо публикации методов как в случае с вебсервисами.
#13 by Fragster
сделали бы REST над веб сервисами, я бы понял
#14 by Лодырь
А зачем? Неужели честно скопипасченных функций от BigB недостаточно? Или скорость неустраивает?
#15 by Fragster
чтобы юзать напрямую из пхп/жабаскрипта
#16 by Лодырь
О другой стороне я и не подумал.
#17 by pumbaEO
RLS, RLS и еще раз RLS надо будет включать.
#18 by SUA
интересно а обычный тонкий клиент следом полетит?
#19 by SUA
и будет ли конфигуратор веб-приложений от 1С (отдельно от конфигуратора БД)?
#20 by dj_serega
если оно туда смотреть будет :)
#21 by Лодырь
Обычный клиент не полетит. Ибо он дефакто основной клиент 1С вообще.
#22 by AaNnDdRrEeYy
уж очень этот тонкий клиент стремный, такси вообще ужас.
#23 by sapphire
Пасиб
#24 by dj_serega
ах да :) спасибо =)
#25 by acsent
думаешь кто-то осилит написать норм клиент?
#26 by sikuda
Движение правильное, но если опять уровень поддержки стандартов так-же как с вэб-сервисами, то опять как всегда...
#27 by xReason
Молодцы, верное направление выбрали
#28 by AaNnDdRrEeYy
на wpf можно что то попробовать сделать, там контролы очень гибко настраивать можно. в правильно заметили, если поддержка урезанная то опять только для галочки "у нас REST есть"
#29 by xReason
Правильно ли я понял, что для этого REST все равно нужен Web-сервер, для того, что бы 1С принимала (получала) запросы. Т.е. когда идет передача (стороний софт) ---> 1C REST ?
#30 by Dunemaster
Да, правильно
#31 by Necessitudo
Ну как бы логично - слава богу пока фирма 1С свой веб-сервер писать не стала.
#32 by xReason
А что им мешает, взять опенсорсный и вкарячить )))
#33 by daniyar5436
чет я не понял была 1С стала БД в скул и морда 1С сейчас морду заберут нафиг тогда вообще нужна 1С если можно на прямую в Скуль лезть? ну надеюсь поняли направление мысли
#34 by badboychik
ВААААУ круто же ) я давно об этом мечтал
#35 by xReason
В скуль может только 1С лезть )) ну и сама 1С это фронтэнд и бизнес-логика
#36 by xReason
Вот только интересно, не надо ли будет клиентская доп. лицензия под это
#37 by badboychik
1С становится сервером приложений, обрабатывающем бизнес-логику, как в нормальных системах на яве например, стандартная практика в корпоративных приложениях
#38 by dj_serega
да наверно нужно будет. web-сервер то нужен же.
#39 by badboychik
теперь ждем расцвета альтернативных оболочек-клиентов на веб-фреймворках
#40 by Asmody
это просто праздник какой-то! можно выкидывать всякие левые прокладки
#41 by badboychik
интеграция с сайтами теперь с полпинка делаться будет, никакие веб-сервисы не надо городить
#42 by daniyar5436
мне тоже начинает нравиться )))
#43 by badboychik
сделали бы еще выгрузку форм в XML, вообще песня была бы - нарисовал форму в конфигураторе, а она в твоем веб-интерфейсе преобразовалась в HTML с каким хочешь оформлением
#44 by Dunemaster
Так просто все не бывает) Наружу, по сути, выставлены потроха конфигурации и выбрать из них информацию нужную для конкретной интеграции может быть не так просто. Для того, чтобы отдать данные сложного отчета все равно придется программировать на стороне 1С
#45 by xReason
жаль, несколько раз попадал на ситуацию, когда уперлись в потолок кол-ва лицензий и из-за этого веб-сервис не срабатывал или COM-подсоединение
#46 by badboychik
это понятно. Просто там ничего не сказано про вызов любых экспортных процедур общих модулей, если это будет, то никаких проблем.
#47 by Necessitudo
Объясните нубу, в чем принципиальная разница между веб-сервисами и вот этой REST?
#48 by Ювелир
Да, интересный поворот.
#49 by badboychik
+ а хотя логику клиента можно будет писать прямо на JavaScript, общие модули останутся только серверные в идеале, это даже плюс
#50 by Necessitudo
Аха, то есть для веб-сервисов мы изначально сами в коде описываем поведением, а в REST будут любые возможности без необходимости нам писать код на встроенном языке?
#51 by IamAlexy
правильно ли я понимаю что можно тогда написать своего "тонкого клиента" на пыхыпы  и не платить за клиентские лицензии ?
#52 by xReason
да, это все проще, быстрее и лаконичные
#53 by badboychik
и REST отлаживать можно в любом браузере, не надо ставить/покупать soapUI
#54 by Dunemaster
Этот интерфейс ориентирован на CRUD-операции, я бы не стал ждать в нем вызовов экспортных процедур общих модулей в ближайшее время.
#55 by Asmody
веб-сервисы (которые были) — это SOAP, целое дело. REST — это тоже веб-сервисы, но работать с ними проще
#56 by Asmody
для этого уже есть SOAP
#57 by acsent
Запросы то можно будет передавать?
#58 by badboychik
тогда промежуточный сервер можно свой написать хоть на яве хоть на РНР, хотя бы например для автоматического тестирования - прогонять документы и проверять их результаты в пакетном режиме или для автоматической записи данных в несколько баз - 1С и на сайт например
#59 by acsent
судя по описанию - нет. Тогда кому они нужны эти рест сервисы?
#60 by xReason
какие запросы? Эх еще бы 1С объект JSON - хотя это по сути просто сложная структура.
#61 by Asmody
самое чудо там — ExecuteTask теперь 1Ску можно "дернуть за волосы" без танцев вокруг
#62 by IamAlexy
так я не понял - потенциально АРМ на рестсервисах сделать можно ?
#63 by Asmody
хороший JSON (де)сериализатор на 1С есть (на ИСе лежит), осталось только встроить его в платформу
#64 by pumbaEO
по скорости хороший?
#65 by badboychik
у 1С есть библиотека для работы с JSON - "Internet Connection Library", я же скачивал с , только они ее убрали сразу
#66 by Serginio1
Кому проще? Для примера в SOAP есть WS-ReliableMessaging. Но в итоге В REST нет отслеживания из коробки. Так приходится самому строить защиту от повторной записи. Ты и с SOAP можешь работать через REST. Никто не запрещает.
#67 by Asmody
для небольших объемов достаточный
#68 by Asmody
для реализации REST в текущем варианте приходится делать "прокладку", которая REST-запросы конвертирует в вызовы SOAP.
#69 by Serginio1
Так объясни на счет легкости. SOAP запрос это тот же Get только с данными отформатированными в XML, где сериализация десериализация автоматическая. Заметь в 1С данные все равно передаются через XML только десериализовывать нужно вручную. Единственный плюс от REST это коды возврата и ручная работа с данными ответа
#70 by Asmody
легкость в том, что 1Ска построит за тебя интерфейсы со всеми чебурашками по нажатию 1 галки.
#71 by badboychik
Что непонятного то? Для SOAP надо писать узконаправленные веб-сервисы с определенным набором параметров и одной функцией на каждый веб-сервис. При REST ты получаешь доступ КО ВСЕМ данным, не написав ничего!
#72 by pumbaEO
вопрос в том, что даст ли возможность отключить для некоторых объектов автогенерацию API...
#73 by badboychik
короче - вебсервисы пишутся каждый под свою задачу, а REST - универсальный доступ ко всей системе
#74 by Asmody
все таки не надо путать. SOAP — это протокол. http при этом — лишь один из возможных транспортов (теоретически, можно и по smtp, например, SOAP-вызовы посылать. на практике я такого не видел). REST — это, скорее, паттерн, и он напрямую завязан на http.
#75 by Asmody
пока известно только [В конфигураторе вы публикуете REST интерфейс - флажок Публиковать стандартный интерфейс OData; После этого объекты прикладного решения становятся доступны через этот интерфейс;]
#76 by Asmody
там в примере интересные пространства имен используются:         xmlns:georss= и xmlns:gml= это они тонко намекают, или я чего-то пропустил?
#77 by Serginio1
Угу. Возьмем для примера Создание нового элемента данных выполняется POST-запросом. В качестве значения ссылки передается нулевой GUID. При создании и модификации объектов значения свойств передаются в теле запроса в формате XML (здесь текст запроса приведён полностью): <entry  xmlns=           xmlns:d=           xmlns:m=           xmlns:georss=           xmlns:gml=; Разбираем различие между методом SOAP ЗаписатьЭлементСправочника(СериализаторXDTO.ЗаписатьXDTO(Объект)) Тоже из Коробки. При этом ты описание получаешь из XDTO итд. Единственный минус это тяжеловесность, но никак не сложность на уровне программирования
#78 by Dunemaster
Это стандартные пространства, используемые OData, т.к. этот протокол поддерживает передачу геолокационных данных
#79 by Dunemaster
Пока да. А потом будет JSON А если писать на .NET там вообще с XML работать не надо, просто объект руками собираешь
#80 by badboychik
вот и надо будет тебе писать огромную SOAP-прослойку в 1С которая будет состоять из функций ЗаписатьЭлементСправочника, ПрочитатьЭлементСправочника, ЗаписатьДокумент, ПрочитатьДокумент, ПрочитатьРегистр, ЗаписатьВРегистр и т.д.
#81 by Serginio1
Ну у JSONа есть куча недостатков. Но это не суть. в Net. можно по разному сериализовывать. Вот чего не хватает в сериализации объекта то это представление ссылки, что бы на клиенте вообще по минимуму заморачиваться. А может есть?
#82 by badboychik
В 8.3 можно представление свое формировать давно
#83 by pumbaEO
ну да с REST все проще, пока не поменяется структура, и дохера клиентов не рухнут, т.к. не обновили код у себя ибо фиг ты сможешь 2 версии держать, даже если одна depricated
#84 by Serginio1
81+ Ну никто и не занимается сериализацией вручную В SOAP это легко делается через WSDL, для модели REST есть WADL, но он пока слабо поддержан инструментально.
#85 by Serginio1
Зачем одного хватит. Объект=СериализаторXDTO.ПрочитатьXDTO(ОбъектXDTO); прекрасно все преобразует. Ну а Get?POST запросы к святому духу что ли обращаются?
#86 by badboychik
ну это проблема не REST а разработчиков, внешние интерфейсы в любой системе рухнут если серверный API поменять.
#87 by Serginio1
85 Вернее хвати 2 ПрочитатьОбъект(Тип) ЗаписатьОбъект(AnyRef)
#88 by Asmody
блин, хочу теперь асинхронные вызовы в 1С
#89 by Asmody
и многопоточность :)
#90 by pumbaEO
ну да расскажи, как ты будешь разработчикам документацию генерить, как один новый реквизит положит половину клиентов, как сможешь за неделю предупредить, что поменялось API и т.д. Если по старинке - ща обновим базу, потом посмотрим кто отвалился, если много воя, тогда вернем обратно.
#91 by Asmody
и функции первого порядка
#92 by pumbaEO
5 модальных диалогов подряд сделай :) но только там процедуры.
#93 by Asmody
с чего-бы новый реквизит положит половину клиентов?
#94 by Dunemaster
Вообще говоря, OData предполагает, что новый реквизит не должен портить других клиентов, если он не является обязательным. И реализовать это не клиентской  стороне очнеь не сложно, в отличие от SOAP, скажем
#95 by Asmody
на клиенте не интересно
#96 by badboychik
Веб-сервис это заранее оговоренная встроенная "единица" системы с прописанными параметрами и названием, и WSDL нужен чтобы разные внешние системы могли эти характеристики прочитать и проверить. А REST слабо регламентирован, зато зная небольшой набор правил, можно совершать любые операции  с данынми в системе. Короче цели у них разные. Веб-сервисы для конкретных сложных действий типа обменов, команд, а REST - для универсального доступа к любому отдельному объекту данных типа COM-соединения.
#97 by GunKata
для каких платформ будет актуально это? только 8.3 ?
#98 by badboychik
это все наверно в 8.3.5 будет или где? Анонсируют но не говорят когда ждать
Тэги: 1С 8
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С

Back to top