Использование REST web-сервисов в "1C:Предприятии 8". Личный опыт.

Опубликовал Dorosh Dorosh (Dorosh) в раздел Обмен - Интеграция с WEB

Часть 1. Чтение данных

Использование REST web-сервисов в "1C:Предприятии 8". Личный опыт.

Когда мне понадобилось использовать REST сервисы в 1С, я столкнулся с "лаконичностью" имеющейся документации и минимумом реальных примеров. Данная статья основана, в первую очередь, на материалах фирмы 1С (http://its.1c.ru/db/metod8dev/content/3790/hdoc/_top/post и http://v8.1c.ru/o7/201312rest/ и https://wonderland.v8.1c.ru/blog/rasshirenie-podderzhki-protokola-odata/) и собственном опыте и призвана немного прояснить тему.

Итак, начнем сначала.

Что такое REST  и зачем он нужен

REST (REpresentation State Transfer) подход является одним из наиболее популярных подходов, использующихся для реализации web-сервисов в Интернете. REST web-сервисы являются более легковесными альтернативами SOAP веб-сервисам.

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

REST определяет следующие принципы построения web-сервисов:

  • Функциональность приложения делится на набор ресурсов. Каждый ресурс может выполнять определенное действие (REST ресурс является аналогом SOAP операции). Например, ресурс получения новостей выдает список заголовков текущих новостей;
  • Каждый ресурс имеет уникальный идентификатор (URL), по которому к нему можно обратиться как из программного кода, так и из Web-браузера;
  • Все ресурсы используют унифицированный интерфейс для передачи данных между клиентом и ресурсом. Интерфейс имеет ограниченный набор операций и типов данных для передачи. Как правило, в качестве транспорта используется инфраструктура HTTP, а набор операций, которые можно выполнить над ресурсом, определяется HTTP стандартом. Наиболее используемыми операциями могут быть: HTTP GET - получение данных от ресурса и HTTP POST отправка данных в ресурс. Также могут использоваться HTTP PUT, HTTP DELETE и т. д.;
  • REST протокол взаимодействия (RESTful) должен быть клиент-серверным и не иметь состояния.

Преимуществами REST подхода являются:

  1. Возможность работы на уже существующей HTTP инфраструктуре - Web-серверах, Web-браузерах и др. 
  2. Простота использования и высокая совместимость между реализациями за счет того, что кодирование данных сведено к минимуму. Кодируются только прикладные данные (т. е. то, что нужно передать), вспомогательная маркировка данных (например, такая как soap:Envelope) не используется.
  3. Хорошая масштабируемость, т. к. REST протоколы не поддерживают состояния между вызовами.
  4. Хорошая безопасность, которая опять-таки основана на HTTP инфраструктуре.

Недостатки REST'а являются продолжением его достоинств:

  1. Сложно использовать вне HTTP, т. к. нет ни соответствующих стандартов, ни существующих реализаций.
  2. Сложно использовать в Entreprise решениях, где требуется поддержка достаточно сложного состояния (например, наличия сессий и др.).
  3. Полная зависимость от транспорта в таких вопросах, как безопасность, маршрутизация сообщений и пр., что может негативно сказаться на работе такого сервиса в гетерогенной среде.

Протокол, который основывается на принципах REST, является RESTful протоколом. Два наиболее популярных типа RESTful протоколов  - это JSON (JavaScript Object Notation) и POX (Plain Old XML). JSON использует для кодирования данных JavaScript и в основном применяется в Ajax (Asynchronous JavaScript and XML) клиентах для обмена данными с сервером. Поскольку Ajax клиенты работают в браузере, который понимает JavaScript, то использование JavaScript  позволяет сэкономить как на объеме передаваемых данных, так и на времени разбора данных. Однако использование JSON в других клиентах проблематично, т. к. клиенты, как правило, не поддерживают JavaScript.

POX использует для кодирования данных XML и поэтому может использоваться практически везде.

REST в 1С

Начиная с версии 8.3.5.1068.  платформа может автоматически формировать REST интерфейс для всего прикладного решения. REST интерфейс позволяет читать данные 1С:Предприятия, изменять их, создавать новые объекты данных и удалять существующие. В качестве протокола доступа платформа использует протокол OData версии 3.0. Это открытый веб-протокол для запроса и обновления данных. Он позволяет оперировать данными, используя в качестве запросов HTTP-команды. Получать ответы можно в различных форматах, но пока платформа поддерживает только работу с данными в формате Atom/XML.

Использовать стандартный интерфейс OData прикладного решения просто:

  • В конфигураторе вы публикуете REST интерфейс - флажок Публиковать стандартный интерфейс OData;
  • После этого объекты прикладного решения становятся доступны через этот интерфейс;
  • Способы аутентификации OData клиентов полностью совпадают со способами, используемыми для веб-сервисов;
  • OData клиенты могут запросить через HTTP документ метаданных, описывающий доступные объекты прикладного решения;
  • OData клиенты выполняют операции создания, чтения, модификации и удаления данных прикладного решения.

По умолчанию после публикации объекты конфигурации не доступны. Прежде чем обращаться к ним, необходимо разрешить доступ, например с помощью типовой обработки "Настройка автоматического REST сервиса". В обработке можно задать отдельного пользователя REST сервиса:

и указать доступные объекты конфигурации:

Чтение данных через REST

Чтение данных выполняется GET-запросом. Сначала устанавливаем HTTPСоединение с базой. Потом формируем текст запроса. Например, получение списка УИДов элементов справочника Контрагенты выглядит так:

/Base1C/odata/standard.odata/Catalog_Контрагенты?$select=Ref_Key&$format=json;odata=nometadata

Что означает это заклинание?

"Base1C" - имя базы, как оно опубликовано на веб-сервере,

"odata/standard.odata" - "магическое" слово, означающее доступ через odata интерфейс

"Catalog_Контрагенты" - состоит из указания на тип объекта "Catalog" - справочник и типа справочника

"select" - оператор чтения данных, после него через "=" идет описание считываемых данных, в данном случае это "Ref_Key" - уникальный идентификатор

"format=json" - задает формат представления считываемых данных JSON

"odata=nometadata" - заклинание, указывающее не передавать в ответе описание метаданных.

Из текста запроса создаем объект HTTPЗапрос:

Запрос = Новый HTTPЗапрос(СтрокаЗапроса);

и отправляем его:

Ответ = HTTPсоединение.Получить(Запрос);

Полученный объект HTTPОтвет надо разобрать, удобнее анализировать строку:

ОтветСтрокой = Ответ.ПолучитьТелоКакСтроку();

Если все хорошо, в ОтветСтрокой находится что-то вроде:

{

"value": [{

"Ref_Key": "a913b5c7-9594-4680-8013-e6a8ff2ef33e"

},{

"Ref_Key": "e29427d9-9cbb-421d-8089-e9859b2427c3"

},{

}

Разобрать ответ можно например так:

		Если Ответ.КодСостояния > 299 Тогда
			ТекстОшибки = "Error, код ошибки: " + Ответ.КодСостояния + "
						|" + ОтветСтрокой;
			
		Иначе
			
			КолСтрок = СтрЧислоСтрок(ОтветСтрокой);
			
			Для НомерСтроки=1 По КолСтрок Цикл
				
				СтрокаАнализа = СтрПолучитьСтроку(ОтветСтрокой, НомерСтроки);
				Если СтрНайти(СтрокаАнализа,"Ref_Key") > 0 Тогда
					ПозицияДо = СтрНайти(СтрокаАнализа, """",НаправлениеПоиска.СКонца);
					ПозицияС = СтрНайти(СтрокаАнализа, """Ref_Key"": """);
					Если (ПозицияС > 0) И (ПозицияДо = (ПозицияС + 48))  Тогда
						НачалоID = ПозицияС + 12;
						GUID = Сред(СтрокаАнализа, НачалоID, 36);
						РезультатМассив.Добавить(GUID);
					КонецЕсли;
					
				КонецЕсли;
				
			КонецЦикла;
			
			БулевРезФун = Истина;
			ТекстОшибки = "OK. Считано элементов: " + Формат(РезультатМассив.Количество(), "ЧН=0; ЧГ=");
			
		КонецЕсли;


Если нужно получить не один реквизит, текст запроса выглядит так:

/Base1C/odata/standard.odata/Catalog_Контрагенты?$select=Ref_Key,Description &$format=json;odata=nometadata

нужные поля добавляются через запятую в select.

Как правило все записи справочника читать не требуется, используем оператор filter:

СтрокаЗапроса = СтрокаЗапроса + "&$filter=Ref_Key eq guid'" + KeyID + "'";

где в KeyID строковое представление УИД

Наименование реквизитов как видите порой неочевидно. Необходимо запомнить:

Code - код,

DeletionMark - пометка удаления,

IsFolder - признак группы,

Parent_Key - родитель.

Если реквизит ссылочного типа, к его имени следует добавить суффикс _Key, например Организация_Key.

Для документов используется схожий синтаксис:

/Base1C/odata/standard.odata/Document_СчетНаОплатуПокупателю?$select=Ref_Key, Number, Date&$format=json;odata=nometadata

 Для документов:

Number - номер документа,

Date - дата документа.

Создание и изменения объектов через REST будет в следующей части.

См. также

Комментарии
1. Петр Базелюк (pbazeliuk) 1218 04.12.16 17:54 Сейчас в теме
Еще, как недостаток, крайняя нестабильность при использовании в системах бизнес-аналитики. Может положить весь кластер "1С:Предприятие" (конфигурация, что падала: 40 Core\192GB RAM\RAID SSD DB\2xSSD tempdb).
2. Иван Коротеев (kiv1c) 274 04.12.16 20:38 Сейчас в теме
тема пересекается с моей статьей про web-сервисы!
http://infostart.ru/public/537861/
насколько я понял, преимущество REST в том, что можно получить какие-то данные и манипулировать объектами сразу, не прописывая код отдельно, как в модулях веб-сервисов?
3. Сергей Старых (tormozit) 4135 04.12.16 22:44 Сейчас в теме
Скриншоты за что так ужал? Не видно же текст.
4. Игорь Пашутин (Alien_job) 110 05.12.16 06:26 Сейчас в теме
Эх, не дошли до самого интересного - до записи. Будете продолжать? Почему-то когда я читаю из базы документ, меняю в ответе один реквизит и пытаюсь записать, то в ответ возвращается всякая ерунда (обычно что не заполнена дата).
5. Dorosh Dorosh (Dorosh) 90 05.12.16 09:26 Сейчас в теме
(1) Не советую использовать REST в бизнес-аналитике. REST в 1с использует оптимистическую блокировку данных. С одной стороны такой подход повышает скорость работы, с другой можно получить не корректные цифры в отчете. Положить кластер у меня пока не получалось, хотя глюков наловил не мало.
6. Dorosh Dorosh (Dorosh) 90 05.12.16 09:29 Сейчас в теме
(2) Хорошая статья, жаль что я не прочитал ее раньше, когда только осваивал работу с веб-сервисами. Основное достоинство REST - производительность. После "прогрева" системы REST сервис работал в 3-10 раз быстрее чем аналогичные по функционалу SOUP сервис. Такая разница стоит мучений.
7. Dorosh Dorosh (Dorosh) 90 05.12.16 09:30 Сейчас в теме
(4) Запись будет в продолжении статьи.
8. v p (vitaliy1911) 7 05.12.16 12:29 Сейчас в теме
Для обработки ответов в JSON удобнее использовать метод ПрочитатьJSON объекта ФабрикаXDTO.
Интересно, каким должен быть HTTP-сервис, чтобы он НЕ удовлетворял принципам REST? Можете привести пример?
Не понятна формулировка "Должен быть клиент-серверным и не иметь состояния". А бывают веб-сервисы не клиент-серверные? Что значит "не иметь состояния"? Например, для выполнения длительных операций сервер сначала возвращает клиенту id операции, чтобы клиент мог периодически опрашивать сервис на факт выполнения этой операции — это можно считать состоянием?
9. Dorosh Dorosh (Dorosh) 90 05.12.16 12:53 Сейчас в теме
(8) Я скорее практик чем теоретик. Состояние реализуется элементарно, на глобальных переменных или РС. Если выполнение кода сервиса зависит от значения глобальной переменной, эта переменная хранит состояние сервиса.
10. Павел Одинцов (Darklight) 05.12.16 17:20 Сейчас в теме
(8)HTTP-Сервис - это чуть более широкое понятие, чем HTTP REST-сервис, который имеет обязательное условие унификации форматов запросов и ответов для всего решения. А самое главное, REST-сервис по определению не должен хранить состояния ( и, т.к. за его исполнение отвечает сама платформа 1С, то она не хранит эти состояния) - нельзя начать какую-либо сессию и потом выполнять REST-запросы в рамках её состояния (а HTTP-сервис такое, в общем-то, может позволить). Тут вся главная фишка именно в том, что REST-сервисы создаёт сама платформа, подчиняя их встроенному в платформу унифицированному формату. И не нужно ничего кодить в источнике REST-сервиса, чтобы обращаться к нему. REST-сервисы это как-бы язык запросов: так же как Вы обращаетесь к СУБД за получением каких-либо данных (или их изменения), так же через происходит взаимодействие через REST - и там и там платформа/СУБД универсально обрабатывает поступившие запросы и возвращает результаты. Один запрос - один результат/действие (пакетных REST обращений не бывает). Соответственно REST-сервис никак не может запустить длительную операцию, а потом её опрашивать. Запустили, получили данные, вернули, завершились.

До не давних пор WEB-Сервисы в 1С не имели возможности хранить состояния сеанса (теперь могут) + необходимость их предварительно кодить на 1С, чтобы использовать - это их главное отличи от REST-Сервисов (но зато WEB-Сервисы более универсальны (ведь в их реализации можно написать любой алгоритм); а области данных, доступ к которым можно получить в ИБ через REST-сейчас очень ограничены, например управлять пользователями нельзя).

REST-Безусловно найдёт своё "место под солнцем" в 1С, скорее у HTTP-сервисов в 1С не так уж много перспектив. Впрочем, сейчас сони вполне могут дополнять REST-сервисы, там, где они ограничены.
11. Василий Василий (VasilVtoroy) 05.12.16 18:15 Сейчас в теме
(1) А вы дампы в 1С посылали?
12. Дмитрий Шерстобитов (DitriX) 2352 06.12.16 01:08 Сейчас в теме
(1) я надеюсь у вас стоит нескоько апачей и используется слабосвязанная система тикетов?
13. v p (vitaliy1911) 7 06.12.16 09:27 Сейчас в теме
(10) можете раскрыть смысл термина "состояние"? что вы в него вкладываете?
14. Павел Одинцов (Darklight) 06.12.16 14:18 Сейчас в теме
(13)В простейшем виде. Состояние - любая управляемая (на которую клиент может целенаправленно влиять) информация, которая сохраняется на сервере после выполнения последней команды, и может быть получена (учтена) при выполнении следующей команды (при этом, при параллельном выполнении множества команд, в т.ч. от разных клиентов) нужная информация (созданная первой командой) будет автоматически (не важно как) сопоставляться со второй командой и соотноситься с исходным клиентом (когда это требуется).
За исключением тривиального примера: когда целем выполнения первой команды есть ТОЛЬКО создание этой информации. А второй команды - только её получение!
Путь будет так, простите, коли запутанно или не точно раскрыл термин. Я не профессор. Понятн, что за уши к этму определению можно приникнуть многое, но делать это не стоит.

(8)Дополнительно поясняю: описанный вам пример является требует наличия состояния на сервере, но не соответствует определению REST-сервиса. Насколько я понимаю, REST-Сервисы вообще не предназначены для запуска выполнения таких фоновых процессов. Но если они уже запущены, или запускаются косвенно после внесения изменений в данные, то формально, можно организовтаь что вы хотите, например так (как уже было предложено в (9)):
1. Допустим на сервере 1С есть регл. задание - которое выполняет какую-либо фоновую обработку (возможно через запуск отдельных фоновых заданий - это не принципиально).
2. Это регл задание, например, мониторит рег. сведений - на наличе записи с запросом на выполнение регл задачи (например произвольного алгоритма из строкового ресурса)
3. Тогда REST запросом - можно внести в этот регистр эту запись + некий ключ
4. Регл. задание это увидит и запусит фоновое выполнение этой задачи, передав ей этот ключ
5. Фоновое задание выполнит переданный алгоритм, например, некоторую часть (как это определяется к сути данного вопроса не относится) и запишет в тот же или другой рег. сведений по имеющемуся ключу результат (окончательный или промежуточный)
6. Внешний процесс через REST-Сервис будет опрашивать этот регистр по тому же ключу на наличие результата.
7. При необходимости через REST-сервис можно внести запись в регистр сведений, что выполнение нужно прервать (или внести изменения)
8. Эту запись то же регл задание может увидеть и прервать выполнение фонового задания с соответствующим ключём (или это может сделать само фоновое задание, тогда оно может внести любое изменения в ход своего выполнения).

Формально говоря, REST-Сервисы можно использовать и для выполнения каких-то фоновых процессов и опроса их результатов. И даже состояние в этом случае сохраняется в информационной базе. Но это лишь обходные уловки, реализация которых требует внесения изменений в конфигурацию. А сами данные состояния клиента, просто хранятся в базе данных. Но тем не менее, описанный мной выше алгоритм взаимодействия вполне может быть использован в рабочих системах.
По-другому запустить выполнение алгоритма через REST-Сервис в 1С (это ограничение текущей реализации 1С 8.3.9) пока нельзя. Но, думаю, со временем это изменится. И тогда, запустить, скажем фоновое выполнение задания можно будет и через REST. Но хранить состояния всё равно нужно будет в ИБ во вспомогательных хранилищах. И это не будет текущим состоянием сеанса. Это буду данные в базе данных.

Варианты хранения такого состояния ограничены лишь тем, что можно сохранить в БД. Например, не удастся так хранить состояние COM -Соединения, или иного сетевого соединения с другим ресурсом (в сети, интернете, или файлом); или оборудованием (подключенном через компоненту). Для многих задач хавтит и описанного способа, но не для всех.
15. Павел Одинцов (Darklight) 06.12.16 14:27 Сейчас в теме
(9)Глобальные переменные не подойдут - при работе с REST-Сервисом их нет. А хранение состояния в регистре сведений возможно - указано мной в (14), но это не то состояние, которое закладывается в определении REST-Сервиса
16. Павел Одинцов (Darklight) 06.12.16 17:12 Сейчас в теме
(14) Вспомнил, что у ряда объектов метаданных (связанных с хранением данных) есть события изменения данных (в самих объектах и в приписках на события). В описании REST-Сервисов про них не сказано, но надо полагать они буду срабатывать, при изменении данных через REST. Соответственно, в предложенном мной примере запуска фонового процесса через REST-сервис регл. задании лишнее - если, скажем в модуле набора записей указанного в (14) регистра сведений в событии "ПриЗаписи" разместить алгоритм, который сам будет запускать фоновые задания, то фоновый процесс будет сразу же запускаться после окончания записи в регистр сведений через REST-вызов. Далее достаточно лишь опрашивать через REST регистр сведений с результатом (по тому же ключу).
Формально, состояние клиента есть, и оно хранится в базе данных (получается по ключу, который сформировал клиент в первом обращении), как и есть возможность периодически опрашивать сервер, для получения промежуточных или итоговых данных.
17. Сергей Смирнов (Serginio) 513 06.12.16 17:42 Сейчас в теме
(16) Вот здесь решали http://www.forum.mista.ru/topic.php?id=785017

Там не только подписки, но и выполнение на сервере итд.
И делать проверку модулей с галками внешнее соединение, сервер
18. Павел Одинцов (Darklight) 07.12.16 10:20 Сейчас в теме
(17) Там один какой-то срач от неправильного применения REST, до неправильно написанных конфигураций 1С.
А вот стыбзенная мистой (или Вами переложенная на мисту) Ваша публикация LINQ to oDATA интересна, хоть и очень коротка (но это уже немного о другом)!
19. Сергей Смирнов (Serginio) 513 07.12.16 12:09 Сейчас в теме
(18) Ну я постарался описать возможность использования и дал ссылочки на использовании компонент .Net.
Сам я её не использую. Но смотрю многие стали интересоваться.
У меня есть еще одна статья про .Net Core .Net Core, WCF и ODATA клиенты
20. Илья Низамов (Region102) 40 07.12.16 13:33 Сейчас в теме
Вообще использование web сервисов для меня это массовость, т.е. ты пишешь какой-то проект на web, а базу 1с используешь как backend. И тут вырисовывается проблема, при этом очень большая, каждое соединение через REST сервис съедает одну лицензию, если не ошибаюсь. Поэтому хорошие люди пишут свои костыли типа metadata.js, реализуя фактически легкий web клиент для высоко нагруженных сервисов обходя проблему лицензирования и не совсем web интерфейса тонкого клиента.
21. Peter Filyk (pfilyk) 07.12.16 14:03 Сейчас в теме
(1) какую BI используете если не секрет, и чем заменили REST?
22. Peter Filyk (pfilyk) 07.12.16 14:07 Сейчас в теме
(6)
(6)
После "прогрева" системы REST

что вы имеете ввиду?
23. Steve Gordon (SGordon1) 07.12.16 15:11 Сейчас в теме
24. Сергей Смирнов (Serginio) 513 07.12.16 16:16 Сейчас в теме
(23) http://www.forum.mista.ru/topic.php?id=679547#4
Объект конфигурации Web-сервис содержит модуль, в котором создаются процедуры на встроенном языке, выполняемые при вызове тех или иных операций Web-сервиса. Типы параметров операций Web-сервиса описываются с помощью типов XDTO и могут представлять собой либо значения XDTO, либо объекты XDTO.

Вызов Web-сервиса происходит следующим образом:

? из пула соединений выбирается подходящее соединение с информационной базой; при отсутствии необходимого соединения соединение создается;

? создается новый сеанс и для созданного сеанса вызывается событие УстановкаПараметровСеанса (в модуле сеанса);

? выполняется вызов затребованного метода Web-сервиса, при этом происходит вызов обработчика УстановкаПараметровСеанса() (в модуле сеанса) каждый раз, когда происходит обращение к неинициализированному параметру сеанса.


Если в пуле нет соединений, то создается новое соединение с загрузкой метаданных, что аналогично запуску 1С с нужной конфигурацией.

Ну и нужно учитывать, что при каждом вызове метода создается новый сеанс и УстановкаПараметровСеанса для web и HTTP сервисов (в том числе и ODATA Rest ) должны быть минимальными по времени.

В новых версиях, программа может выбирать нужный сеанс из пула при этом УстановкаПараметровСеанса производиться не будет.

Повышение производительности веб-сервисов

В версии 8.3.9 мы доработали механизм веб-сервисов (SOAP-сервисы, HTTP-сервисы, сервисы OData). В результате их производительность увеличилась примерно в 10 раз.
Мы проводили тесты на типовой конфигурации Бухгалтерия предприятия. В неё мы добавили HTTP-сервисы, выполняющие выборку из справочника Контрагенты. Тест заключался в том, что клиент выполнял последовательно 100 обращений к сервису. В старом режиме работы для этого потребовалось 29,9 с. В новых режимах работы в среднем 3 с.
Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:
Автоматическое переиспользование сеансов из пула;
Управление сеансами с помощью HTTP-заголовков.
При автоматическом переиспользовании сеансов клиент не имеет возможности влиять на количество сеансов и время их жизни. Ему просто автоматически выделяется сеанс из существующего пула сеансов. Такая стратегия подходит для высоконагруженных публичных сервисов, к которым обращаются клиенты, выполняющие шаблонные операции, и обладающие унифицированными привилегиями.
Например, это может быть автоматизация торговой деятельности удаленных торговых точек, предусматривающая периоды пиковой нагрузки на сервер. Для обработки будет выделено нужное количество сеансов. Они будут завершены по мере падения нагрузки.
Другой пример это получение/помещение файлов в конфигурации Документооборот посредством http-сервисов. Для таких операций можно использовать одного и того же специального пользователя.
Стратегия ручного управления сеансами подразумевает, что клиент самостоятельно управляет количеством сеансов и временем их жизни. Эта стратегия лучше подходит для высокоинтегрированных систем в рамках одной организации. Вы можете реализовать собственный алгоритм, который будет управлять временем жизни сеансов и их количеством
25. Dorosh Dorosh (Dorosh) 90 07.12.16 20:09 Сейчас в теме
(22) В (24) подробно описано. Первое обращение к сервису вызывает загрузку и инициализацию используемых библиотек. Оно всегда долгое и учитывать его в замере производительности неверно.
26. Максим *** (premier) 131 10.12.16 12:55 Сейчас в теме
(0) Автор, а почему код ответа больше 299 Вы считаете кодом ошибки?
Вот, например описание кодов ответов более 299:
3xx: Redirection (перенаправление):
300 Multiple Choices («множество выборов»)[2][6].
301 Moved Permanently («перемещено навсегда»)[2][6].
302 Moved Temporarily («перемещено временно»)[2][6].
302 Found («найдено»)[6].
303 See Other (смотреть другое)[2][6].
304 Not Modified (не изменялось)[2][6].
305 Use Proxy («использовать прокси»)[2][6].
306 — зарезервировано (код использовался только в ранних спецификациях)[6].
307 Temporary Redirect («временное перенаправление»)[6].
Эти коды вполне можно тоже обрабатывать. Если сервер сделал redirection, это не значит, что он ваш запрос не обработал или выдал предупреждение об ошибке. В HTTPОтвете, с таким кодом ответа в параметре location, если я не ошибаюсь, должен содержаться URL перенаправления.
27. Александр Шипков (sansys) 28 07.01.17 12:08 Сейчас в теме
Очень познавательная статья, пошёл экспериментировать. +1
28. Дмитрий Копейкин (nodalt) 3 18.01.17 17:09 Сейчас в теме
Спасибо за статью.
В тексте:
Получать ответы можно в различных форматах, но пока платформа поддерживает только работу с данными в формате Atom/XML
- вот тут не понял. Ответ же можно получить в формате JSON. Собственно, это далее и демонстрируется ...
29. Алекс Одинэсник (Alex1Cnic) 118 24.01.17 08:18 Сейчас в теме
Мне понравилось, написано просто и ясно, ждем продолжения....
30. Алексей Роза (DoctorRoza) 26.01.17 12:11 Сейчас в теме
31. kiruha Дронов (kiruha) 357 07.02.17 14:57 Сейчас в теме
А где посмотреть полную справку по запросам Rest в 1С ? Во встроенной справке не вижу.
32. kiruha Дронов (kiruha) 357 07.02.17 15:05 Сейчас в теме
+ интересует скорость такого обмена по сравнению с аналогичными веб сервисами