Вот они чего наделали
http://v8.1c.ru/o7/201312rest/index.htm

веб расширение хоронят

вебрасширение и так не нужно было

а как же "тыкать" по кнопочкам в 1с? ых...

и пусть хоронят, если есть что то более новое и лучшее

вообще круть

еще бы json прикрутили

вот оно че (может кто не дочитает =) ):
Поэтому развитие и поддержку web-расширения мы планируем прекратить.

(6) а ты его юзал?

(7)+ я ни одного человека не знаю, кто бы юзал.

(7) я разрабатывал :) а юзали пользователи :)
как по мне лучше бы и REST и web развивали дальше.
Не хочу ничего стороннего покупать/устанавливать если нужно с web-а в 1С достучаться.

(9) веб-сервер по-любому нужен

(10) а Web-расширение жалко.

(9) дык соап же.

в тренде json (по крайней мере, безгеморно в обе стороны).

А тут какая-то заляпуха, позволяющая напрямую изменять данные в 1ске вместо публикации методов как в случае с вебсервисами.

сделали бы REST над веб сервисами, я бы понял

(5) А зачем? Неужели честно скопипасченных функций от BigB недостаточно? Или скорость неустраивает?

(14) чтобы юзать напрямую из пхп/жабаскрипта

(15) О другой стороне я и не подумал.

RLS, RLS и еще раз RLS надо будет включать.

интересно а обычный тонкий клиент следом полетит?

и будет ли конфигуратор веб-приложений от 1С (отдельно от конфигуратора БД)?

(17) если оно туда смотреть будет :)

(18) Обычный клиент не полетит. Ибо он дефакто основной клиент 1С вообще.

(18) уж очень этот тонкий клиент стремный, такси вообще ужас.

(0) Пасиб

(0) ах да :) спасибо =)

(22) думаешь кто-то осилит написать норм клиент?

(0) Движение правильное, но если опять уровень поддержки стандартов так-же как с вэб-сервисами, то опять как всегда...

Молодцы, верное направление выбрали

(25) на wpf можно что то попробовать сделать, там контролы очень гибко настраивать можно. в (26) правильно заметили, если поддержка урезанная то опять только для галочки "у нас REST есть"

(10) Правильно ли я понял, что для этого REST все равно нужен Web-сервер, для того, что бы 1С принимала (получала) запросы. Т.е. когда идет передача (стороний софт) ---> 1C REST

?

Да, правильно

(29) Ну как бы логично - слава богу пока фирма 1С свой веб-сервер писать не стала.

(31) А что им мешает, взять опенсорсный и вкарячить )))

чет я не понял была 1С стала БД в скул и морда 1С сейчас морду заберут нафиг тогда вообще нужна 1С если можно на прямую в Скуль лезть? ну надеюсь поняли направление мысли

ВААААУ
круто же ) я давно об этом мечтал

(33) В скуль может только 1С лезть ))
ну и сама 1С это фронтэнд и бизнес-логика

Вот только интересно, не надо ли будет клиентская доп. лицензия под это

(33) 1С становится сервером приложений, обрабатывающем бизнес-логику, как в нормальных системах на яве например, стандартная практика в корпоративных приложениях

(36) да наверно нужно будет. web-сервер то нужен же.

теперь ждем расцвета альтернативных оболочек-клиентов на веб-фреймворках

(0) это просто праздник какой-то! можно выкидывать всякие левые прокладки

интеграция с сайтами теперь с полпинка делаться будет, никакие веб-сервисы не надо городить

мне тоже начинает нравиться )))

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

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

Для того, чтобы отдать данные сложного отчета все равно придется программировать на стороне 1С

(38) жаль, несколько раз попадал на ситуацию, когда уперлись в потолок кол-ва лицензий и из-за этого веб-сервис не срабатывал или COM-подсоединение

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

Объясните нубу, в чем принципиальная разница между веб-сервисами и вот этой REST?

Да, интересный поворот.

+(46) а хотя логику клиента можно будет писать прямо на JavaScript, общие модули останутся только серверные в идеале, это даже плюс

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

правильно ли я понимаю что можно тогда написать своего "тонкого клиента" на пыхыпы  и не платить за клиентские лицензии ?

(50) да, это все проще, быстрее и лаконичные

(52) и REST отлаживать можно в любом браузере, не надо ставить/покупать soapUI

(46) Этот интерфейс ориентирован на CRUD-операции, я бы не стал ждать в нем вызовов экспортных процедур общих модулей в ближайшее время.

(47) веб-сервисы (которые были) — это SOAP, целое дело. REST — это тоже веб-сервисы, но работать с ними проще

(46) для этого уже есть SOAP

Запросы то можно будет передавать?

(54) тогда промежуточный сервер можно свой написать хоть на яве хоть на РНР, хотя бы например для автоматического тестирования - прогонять документы и проверять их результаты в пакетном режиме или для автоматической записи данных в несколько баз - 1С и на сайт например

(57) судя по описанию - нет. Тогда кому они нужны эти рест сервисы?

(57) какие запросы?

Эх еще бы 1С объект JSON - хотя это по сути просто сложная структура.

самое чудо там — ExecuteTask()
теперь 1Ску можно "дернуть за волосы" без танцев вокруг

так я не понял - потенциально АРМ на рестсервисах сделать можно ?

(60) хороший JSON (де)сериализатор на 1С есть (на ИСе лежит), осталось только встроить его в платформу

(63) по скорости хороший?

(63) у 1С есть библиотека для работы с JSON - "Internet Connection Library", я же скачивал с http://www.1c-dn.com, только они ее убрали сразу

(47) wiki:REST
(55) Кому проще? Для примера в SOAP есть WS-ReliableMessaging. Но в итоге В REST нет отслеживания из коробки. Так приходится самому строить защиту от повторной записи.
Ты и с SOAP можешь работать через REST. Никто не запрещает.

(64) для небольших объемов достаточный

(66) для реализации REST в текущем варианте приходится делать "прокладку", которая REST-запросы конвертирует в вызовы SOAP.

(68) Так объясни на счет легкости. SOAP запрос это тот же Get только с данными отформатированными в XML, где сериализация десериализация автоматическая. Заметь в 1С данные все равно передаются через XML только десериализовывать нужно вручную.
Единственный плюс от REST это коды возврата и ручная работа с данными ответа

(69) легкость в том, что 1Ска построит за тебя интерфейсы со всеми чебурашками по нажатию 1 галки.

(69) Что непонятного то? Для SOAP надо писать узконаправленные веб-сервисы с определенным набором параметров и одной функцией на каждый веб-сервис. При REST ты получаешь доступ КО ВСЕМ данным, не написав ничего!

(70) вопрос в том, что даст ли возможность отключить для некоторых объектов автогенерацию API...

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

все таки не надо путать. SOAP — это протокол. http при этом — лишь один из возможных транспортов (теоретически, можно и по smtp, например, SOAP-вызовы посылать. на практике я такого не видел). REST — это, скорее, паттерн, и он напрямую завязан на http.

(72) пока известно только [В конфигураторе вы публикуете REST интерфейс - флажок Публиковать стандартный интерфейс OData;
После этого объекты прикладного решения становятся доступны через этот интерфейс;]

там в примере интересные пространства имен используются:         xmlns:georss=http://www.georss.org/georss и xmlns:gml=http://www.opengis.net/gml

это они тонко намекают, или я чего-то пропустил?

(71) Угу. Возьмем для примера
Создание нового элемента данных выполняется POST-запросом. В качестве значения ссылки передается нулевой GUID. При создании и модификации объектов значения свойств передаются в теле запроса в формате XML (здесь текст запроса приведён полностью):
POST  /OData_Tests_Infobase/odata/standard.odata/Catalog_Goods HTTP/1.1
Content-Type: application/atom+xml
DataServiceVersion: 3.0;NetFx
MaxDataServiceVersion: 3.0;NetFx
Accept: application/atom+xml,application/xml
Accept-Charset: UTF-8
User-Agent: 1C-Enterprise
Host: test-host:8090
Content-Length: 1610

<?xml  version="1.0" encoding="utf-8"?>
<entry  xmlns=http://www.w3.org/2005/Atom  
        xmlns:d=http://schemas.microsoft.com/ado/2007/08/dataservices  
        xmlns:m=http://schemas.microsoft.com/ado/2007/08/dataservices/metadata  
        xmlns:georss=http://www.georss.org/georss  
        xmlns:gml=http://www.opengis.net/gml>;

   <category term="EnterpriseV8.CatalogGoods"  scheme=http://schemas.microsoft.com/ado/2007/08/dataservices/scheme />
   <id />
   <title />
   <updated>2013-08-12T11:48:25Z</updated>
   <author>
      <name />
   </author>
   <content type="application/xml">
      <m:properties>
         <d:Code>157</d:Code>
         <d:DeletionMark>false</d:DeletionMark>
         <d:Description>Майка синяя</d:Description>
         <d:IsFolder>false</d:IsFolder>
         <d:Parent_Key m:null="true" />
         <d:Ref_Key m:type="Edm.Guid">00000000-0000-0000-0000-000000000000</d:Ref_Key>
         <d:Артикул m:null="true" />
         <d:Поставщик_Key>F400322D-7AE8-4803-A7BE-0D80E525E8C2</d:Поставщик_Key>
      </m:properties>
   </content>
</entry>

Разбираем различие между методом SOAP

ЗаписатьЭлементСправочника(СериализаторXDTO.ЗаписатьXDTO(Объект))
Тоже из Коробки. При этом ты описание получаешь из XDTO итд.
Единственный минус это тяжеловесность, но никак не сложность на уровне программирования

(76) Это стандартные пространства, используемые OData, т.к. этот протокол поддерживает передачу геолокационных данных

(77) Пока да. А потом будет JSON

А если писать на .NET там вообще с XML работать не надо, просто объект руками собираешь

(77) вот и надо будет тебе писать огромную SOAP-прослойку в 1С которая будет состоять из функций ЗаписатьЭлементСправочника, ПрочитатьЭлементСправочника, ЗаписатьДокумент, ПрочитатьДокумент, ПрочитатьРегистр, ЗаписатьВРегистр и т.д.

(79) Ну у JSONа есть куча недостатков. Но это не суть. в Net. можно по разному сериализовывать. Вот чего не хватает в сериализации объекта то это представление ссылки, что бы на клиенте вообще по минимуму заморачиваться. А может есть?

(81) В 8.3 можно представление свое формировать давно

(80) ну да с REST все проще, пока не поменяется структура, и дохера клиентов не рухнут, т.к. не обновили код у себя ибо фиг ты сможешь 2 версии держать, даже если одна depricated

81+ Ну никто и не занимается сериализацией вручную
В SOAP это легко делается через WSDL,
для модели REST есть WADL, но он пока слабо поддержан инструментально.

(80) Зачем одного хватит.
Объект=СериализаторXDTO.ПрочитатьXDTO(ОбъектXDTO);
прекрасно все преобразует.

Ну а Get?POST запросы к святому духу что ли обращаются?

(83) ну это проблема не REST а разработчиков, внешние интерфейсы в любой системе рухнут если серверный API поменять.

85 Вернее хвати 2
ПрочитатьОбъект(Тип)
ЗаписатьОбъект(AnyRef)

блин, хочу теперь асинхронные вызовы в 1С

и многопоточность :)

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

Если по старинке - ща обновим базу, потом посмотрим кто отвалился, если много воя, тогда вернем обратно.

и функции первого порядка

(88) 5 модальных диалогов подряд сделай :) но только там процедуры.

(90) с чего-бы новый реквизит положит половину клиентов?

(90) Вообще говоря, OData предполагает, что новый реквизит не должен портить других клиентов, если он не является обязательным. И реализовать это не клиентской  стороне очнеь не сложно, в отличие от SOAP, скажем

(92) на клиенте не интересно

Веб-сервис это заранее оговоренная встроенная "единица" системы с прописанными параметрами и названием, и WSDL нужен чтобы разные внешние системы могли эти характеристики прочитать и проверить. А REST слабо регламентирован, зато зная небольшой набор правил, можно совершать любые операции  с данынми в системе.
Короче цели у них разные. Веб-сервисы для конкретных сложных действий типа обменов, команд, а REST - для универсального доступа к любому отдельному объекту данных типа COM-соединения.

для каких платформ будет актуально это? только 8.3 ?

это все наверно в 8.3.5 будет или где? Анонсируют но не говорят когда ждать