в чем разница между http сервисом и web сервисом
Web-сервисы vs HTTP-сервисы
Доброго времени суток.
Коллеги, когда предпочтительнее использовать Web-сервисы, а когда HTTP-сервисы?
Если верить этому сайту, то лучше всегда использовать HTTP-сервисы (ну разве есть кто-то, кому не нужна уменьшить объем передаваемых данных и вычислительную нагрузку). Так ли эта?
так же более трудоемкая работа для реализации взаимодействия с сервисом, банально больше кода писать.
Это уже почти прошлый век, практически везде (имею ввиду не только 1С) уже от них отошли в пользу «HTTP сервисов» + REST
То же сообщение «hello world» при использовании HTTP сервисов может иметь вид
Меньше трафика, быстрее работа, но валидация ложится на создателя, так же легко генерить ответы HTTP сервиса на стороне 1С, т.е. обычно код построения ответа выглядет так
Функция СоздатьHTTPОтвет содержит обычно строк 20-100 кода под копотом, все что она делает, это преобразует к JSON объект 1С, через ЗаписьJSON и возвращает HTTPСервисОтвет, описав в ней пару правил превращения ссылочных объектов и ТЗ (изначально ЗаписьJSON не умеет в ТЗ и ссылочные объекты) она будет +- универсальна для всех сервисов и не надо писать код для конвертации / описывать схемы каждого объекта по отдельности как это часто бывает с веб сервисами
Еще я прикрутил конвертацию результатов СКД (из дерева значений) в JSON и храню макеты ответов сервиса, добавить \ убрать \ отключить какой то реквизит из ответа сейчас дело 30 сек, открыть настройки СКД и произвести нужное действие и кодировать ответы вообще не приходится, все делается через СКД.
И чуть не забыл про приятный бонус, в любой конфе есть уже готовые HTTP сервисы на базе протокола oData, при простых случаях кодировать сервис вообще не приходится, достаточно юзать его.
Мой опыт HTTP-сервисов в 1С
Посыпаю голову пеплом, но до некоторого времени я не знал, в чем разница между веб-сервисами и HTTP-сервисами в 1С. С первыми я достаточно плотно работал, а про существование других даже не догадывался.
Забавно, что перед тем, как начать работать с HTTP-сервисами, в одном из обсуждений я прочитал, что кандидату на должность программиста задавали как раз вопрос, чем эти два сервиса отличаются друг от друга.
Но на практике все оказалось просто. Веб-сервис — это сложный протокол SOAP. А для HTTP-сервиса достаточно написать строку в браузере (если речь о протоколе GET) и 1С может возвращать данные в любом формате по этому запросу — хоть JSON, хоть XML, хоть HTML.
По сути веб-сервис — это удаленный вызов функции, с вызывающей стороны требуется поддержка SOAP. А HTTP-сервис — это простейший вызов по http-адресу, его проще вызывать.
Написав пару простейших Get-запросов я отлаживал их на опубликованной на веб-сервере IIS файловой базе, набирая адрес запроса в адресной строке.
Я знаю, что можно отлаживать HTTP-сервисы, но такой возможностью не пользовался.
Метод-обработчик HTTP-сервиса вызывать в консоли кода нельзя, поэтому у меня эти обработчики просто тупо вызывали процедуры из модуля сервера, а уже эти процедуры я мог отладить в консоли:
Однако далее мне пришлось писать POST-запросы. Тут уже для вызова веб-сервера я использовал страницу reqbin.com/post-online. 1С на ИТС рекомендует использовать специальную программу, но ее надо скачивать и ставить, а тут можно проверить онлайн.
При этом нужно помнить, что нужно указать авторизацию, причем имя пользователя на русском этот сайт не понимает, завел пользователя на английском:
В адрес я ввожу адрес POST-запроса, выбираю метод POST, ввожу содержимое запроса (JSON) после чего нажимаю SEND и получаю ответ (JSON) в правом окошке.
Сначала ответ был не читаем, помогло правильное прописывание кодировки. Вот кстати, как возвращать ответ HTTP-сервиса:
Однако по странному изгибу мысли заказчика у меня возникла проблема. Дело в том, что создание заказа выполнялось через часть URL post, а изменение заказа через часть URL post/guid.
Т.е. если раньше у меня был один шаблон URL на каждый метод, тут пришлось сделать два шаблона и я не сразу понял, как это должно выглядеть. Но потом догадался, в итоге вышло так:
orderCreate имеет шаблон /order, а orderWork имеет шабон /order/
Соответственно, для отладки PATCH-запросов я использую тот же сайт, только выбираю метод PATCH.
Со временем я столкнулся с ошибкой, которую не смог выявить без отладки, поэтому написал небольшую обработку, где вводил JSON-текст запроса, а она уже имитировала вызов метода сервиса:
Вот её код, я здесь передаю настоящий, правда виртуальный, HTTPЗапрос:
WEB и HTTP сервисы в 1С: отличия и применение на практике
Рассказываем о WEB и HTTP сервисах, их отличиях и практическом применении. О шишках, которые мы набили, и о выводах, которые сделали. Спойлер: тех, кто дочитает статью до конца, ждет бонус от автора.
WEB и HTTP сервисы — две технологии, позволяющие получить доступ к 1С из внешней системы. Причем можно получить доступ как за файрволом, так и через прокси. В общем, практически из любой точки земного шара.
С точки зрения 1С, это два объекта метаданных, которые позволяют нам выполнять эти операции. Реализовывается доступ по классической трехзвенной схеме: это СУБД, в качестве сервера выступают кластер серверов 1С и веб-серверы, и клиент, подключающийся к сервису.
Зачем это нужно?
Изначально сервисы разрабатывались для поддержки внешних систем: сайтов, интернет-магазинов, корпоративных порталов. В дальнейшем технология получила широкое распространение и сейчас используется в широком спектре схожих задач:
В качестве примера можно привести сервис обмена данными, который в типовых конфигурациях в части передачи данных реализован также на WEB сервисах. По сравнению с традиционными COM-соединениями он намного более быстр, а информационные базы в этом случае могут базироваться на абсолютно разных платформах: как на версиях, так и на разных операционных системах.
HTTP сервисы, поскольку они достаточно просты, могут выполняться на несложных и недорогих устройствах: таких как микрооборудование, телефония, терминалы сбора данных, электронные весы и так далее. Например, из 1С можно обратиться к IP-телефону, АТС или системе контроля доступа. В нашей практике был кейс, когда с телефонов Yealink вызывался сервис 1С, который записывал входящие звонки. Также это работало и в обратную сторону, и мы могли позвонить непосредственно с карточки клиента одним нажатием кнопки. Реализовывается это легко и быстро.
Благодаря HTTP сервисам мы можем использовать мощь технологий HTML, PHP, JavaScript для того, чтобы предоставлять интерфейс для конечных пользователей. Причем интерфейс может быть быстрым и легким, для него не потребуется загружать всю платформу. Нам необходимо будет сделать всего лишь страничку, которая будет передавать данные на сервис HTTP.
В нашей практике был случай, когда для заказчика нужно было сформировать внешнюю печатную форму на основании обязательной анкеты, которую заполняли клиенты на специальном планшете. Для этого для планшета была сделана веб-страничка. И пока клиенты ждали своей очереди, они заполняли эту страничку, проставляя галки в нужных местах. При нажатии на кнопку «Отправить» данные отправлялись на сервис 1С, где уже всей мощью платформы формировался документ PDF с печатью и подписью, который затем распечатывался и прикреплялся к данным клиента. Все это было сделано за полтора дня, без изменений типовой конфигурации, в расширении.
Такая страничка с двумя полями уже может передавать данные на внешний HTTP сервис:
Ниже скрин HTTP/WEB сервисов, которые используются у нас на текущем проекте. Обилие сервисов только подтверждает, что технология перспективная и очень интересная:
Ну, и самое последнее — это создание API для внешних систем, для сторонних партнеров. Дальше мы расскажем об этом подробнее.
WEB и HTTP сервисы: сходства и отличия
WEB и HTTP сервисы очень сходны между собой, но все же в них есть кардинальные отличия. Сходны они тем, что:
Теперь расскажем о различиях.
WEB сервисы — это сервисно-ориентированная технология, она по сути является удаленным вызовом процедур. Мы проектируем описание процедур, описание передаваемых параметров, и с помощью WEB сервисов мы эти процедуры можем вызывать. 1С со своей стороны также предоставляет технологию XDTO, которая позволяет валидировать входящие и исходящие данные, передаваемые в формате XML.
HTTP сервисы же основаны практически на голом HTTP, и эта технология ресурсно-ориентированная. Нет описания, нет проверки типов, нет проверки входящих и исходящих данных — есть только заголовки, параметры и тело запроса. И исторически используется формат данных JSON.
Логично что WEB-сервисы потенциально сложнее в реализации, потенциально используют больший объем передаваемых данных и дают потенциально большую вычислительную нагрузку.
О форматах данных
Примерно так выглядит XML:
Это, кстати, хороший формат, позволяющий закодировать практически любые данные. А его мощь обеспечивает возможность создания шаблонов XML — XSD-схем, что описывают формат и допустимые типы данных.
Именно поэтому его используют различного рода госорганы.
А так выглядит JSON — формат немного попроще:
Здесь есть основные типы данных: это объекты, формируемые фигурными скобками, массивы, формируемые квадратными скобками, и значение, которое формируется в виде текста.
Данные для HTTP-сервиса передаются в виде запроса HTTP, схематично изображенного ниже:
Он состоит из строки запроса, из заголовка запроса, который представляет собой ключ и значение, также есть пустая строка и тело запроса в виде обычного текста. В теле запроса можно передавать любые данные, в том числе и двоичные, предварительно закодировав их в base64.
Так выглядит строка запроса в HTTP сервисе:
Сервис HTTP ресурсно-ориентирован. Конечные точки, к которым мы можем обращаться, являются ресурсами: они представлены именами существительными. На схеме это элементы строки orders и status, обозначающие соответственно ресурсы «Заказ» и «Статус заказа». Действия над ресурсами выполняются методами HTTP, базовыми из которых являются: get (получить ресурс), post (добавить ресурс), put (обновить ресурс), delete (удалить ресурс). Количество методов HTTP ограничено, действия над ресурсами тоже. Помимо указанных методов есть еще несколько дополнительных, но используются они значительно реже.
Также имеет место понятие коллекции: несколько ресурсов одного типа, из которых можно выбрать один по идентификатору.
Про проектирование
Теперь мы поделимся той болью, которую мы пережили при проектировании API с клиентами и партнерами. И теми шагами, которые необходимо предпринять, чтобы эту боль в будущем чуть-чуть уменьшить.
При создании API предполагается, что пользоваться им будем не только мы, но и партнеры, и пользоваться достаточно долгое время. Здесь не обойтись без тщательного и взвешенного проектирования. Каждый момент должен быть учтен.
Вспоминаем, что HTTP сервис — это у нас, в первую очередь, ресурсы. А ресурсы — это имена существительные: вот таких элементов, как /GetOrders или /orders/add, где в качестве ресурсов явно указываются глаголы действия, быть не должно. В качестве действий у нас должны выступать методы HTTP (get, post, delete).
Правильное проектирование обычно идет по иерархии: коллекция, элемент, ресурс. И вот здесь мы специально отобразили один интересный момент, связанный с особенностями ресурсной иерархии. Например, к заказу у нас прикрепляются накладные. Есть заказ, есть накладные, которые выдаются по этому заказу (одна или несколько). К этим накладным мы можем дать доступ и как к отдельному ресурсу /invoices, и как к ресурсу в составе заказа — когда накладная сделана на основе заказа /orders/
Для проектирования рекомендуется элементы, ресурсы и действия сводить в таблицу, где в строках располагаются ресурсы, а в столбцах — методы HTTP. На пересечениях строк и столбцов — описание, что должно выполняться в данном случае. Пример таблицы:
Благодаря этому мы понимаем, какое действие у нас происходит в случае применения каждого из методов HTTP к соответствующему ресурсу, а также можем легко расширять набор ресурсов и действий над ними.
Про документацию
Если первый по важности пункт — это проектирование, второй — обязательно документация. HTTP протокол, HTTP сервисы не имеют описания, как это сделано в WEB сервисах. Поэтому документацию необходимо создавать, вести и обязательно поддерживать. Тем более, что ей пользуемся не только мы, но и партнеры.
В самом начале мы «забивали» на документацию, а когда партнеры спрашивали, каково предназначение того или иного метода, и что он в итоге принимает и возвращает — приходилось лезть в код. Теперь же мы просто говорим: посмотрите документацию, там все есть.
Документацию мы рекомендуем вести в таком виде:
Вот пример документации. Заголовок, ответ, пример, описание полей данных:
Будь мужиком! Пиши логи!
На первых порах логи пишем всегда и везде. При получении запроса от нашего партнера — пишем в журнал все данные запроса, включая тело. При формировании ответа в критически важных участках кода примечания пишем в лог. При передаче запроса партнеру также пишем его в лог. Когда отправляем партнеру ответ, пишем в лог. Когда мы сами обращаемся к партнеру, пишем в лог. Ну, и при сбое, вы уже поняли, что мы делаем.
Разделяй код и властвуй над ним
Еще один очень важный момент при проектировании, при разработке таких систем — это разделение методов обработки самого HTTP запроса и методов обработки данных, которые являются методами бизнес-логики. Сначала мы делаем обработку самого HTTP запроса, расшифровываем заголовки, тело запроса и результаты передаем в процедуры обработки данных, в другой модуль — модуль бизнес-логики. Для формирование тела запроса и запроса партнеру имеет смысл использовать отдельные общие методы, включающие в себя автоматический вызов функций логирования. И, естественно, мы должны выполнять начальный контроль данных, потому что, в отличие от WEB сервисов, контроль данных у нас не производится.
На примере этого кода продемонстрировано использование указанных выше правил:
В данном случае метод выполняет получение прайса от партнера. При получении производится запись запроса в лог с указанием имени сервиса. Затем выполняется разбор запроса, подготовка данных и формирование ответа на запрос.
Разбор запроса включает в себя чтение и подготовку всех параметров запроса, проверку обязательных параметров и валидацию их корректности.
После подготовки данных вызывается модуль бизнес-логики, где происходит обработка данных. Результат обработки возвращается в виде структуры, после чего происходит формирование тела ответа.
Ну и тем, кто дочитал до конца, автор этой статьи предлагает свою демонстрационную базу: он выполнил все указанные принципы, перенес код из работающей системы и делится с вами безвозмездно (то есть даром).
WEB/HTTP сервисы. Базовые отличия и применение на практике
WEB и HTTP сервисы — две технологии, позволяющие получить доступ к 1С из внешней системы. Причем можно получить доступ как за файрволом, так и через прокси. В общем, практически из любой точки земного шара.
С точки зрения 1С, это два объекта метаданных, которые позволяют нам выполнять эти операции. Реализовывается доступ по классической трехзвенной схеме: это СУБД, в качестве сервера выступают кластер серверов 1С и веб-серверы, и клиент, подключающийся к сервису.
Зачем это нужно?
Изначально сервисы разрабатывались для поддержки внешних систем: сайтов, интернет-магазинов, корпоративных порталов. В дальнейшем технология получила широкое распространение и сейчас используется в широком спектре схожих задач:
В качестве примера можно привести сервис обмена данными, который в типовых конфигурациях в части передачи данных реализован также на WEB сервисах. По сравнению с традиционными COM-соединениями он намного более быстр, а информационные базы в этом случае могут базироваться на абсолютно разных платформах: как на версиях, так и на разных операционных системах.
HTTP сервисы, поскольку они достаточно просты, могут выполняться на несложных и недорогих устройствах: таких как микрооборудование, телефония, терминалы сбора данных, электронные весы и так далее. Например, из 1С можно обратиться к IP-телефону, АТС или системе контроля доступа. В нашей практике был кейс, когда с телефонов Yealink вызывался сервис 1С, который записывал входящие звонки. Также это работало и в обратную сторону, и мы могли позвонить непосредственно с карточки клиента одним нажатием кнопки. Реализовывается это легко и быстро.
Благодаря HTTP сервисам мы можем использовать мощь технологий HTML, PHP, JavaScript для того, чтобы предоставлять интерфейс для конечных пользователей. Причем интерфейс может быть быстрым и легким, для него не потребуется загружать всю платформу. Нам необходимо будет сделать всего лишь страничку, которая будет передавать данные на сервис HTTP.
В нашей практике был случай, когда для заказчика нужно было сформировать внешнюю печатную форму на основании обязательной анкеты, которую заполняли клиенты на специальном планшете. Для этого для планшета была сделана веб-страничка. И пока клиенты ждали своей очереди, они заполняли эту страничку, проставляя галки в нужных местах. При нажатии на кнопку «Отправить» данные отправлялись на сервис 1С, где уже всей мощью платформы формировался документ PDF с печатью и подписью, который затем распечатывался и прикреплялся к данным клиента. Все это было сделано за полтора дня, без изменений типовой конфигурации, в расширении.
Такая страничка с двумя полями уже может передавать данные на внешний HTTP сервис:
Ниже скрин HTTP/WEB сервисов, которые используются у нас на текущем проекте. Обилие сервисов только подтверждает, что технология перспективная и очень интересная:
Ну, и самое последнее — это создание API для внешних систем, для сторонних партнеров. Дальше мы расскажем об этом подробнее.
WEB и HTTP сервисы: сходства и различия
WEB и HTTP сервисы очень сходны между собой, но все же в них есть кардинальные отличия. Сходны они тем, что:
Теперь расскажем о различиях.
WEB технология — это сервисно-ориентированная технология, она по сути является удаленным вызовом процедур. Мы проектируем описание процедур, описание передаваемых параметров, и с помощью WEB сервисов мы эти процедуры можем вызывать. 1С со своей стороны также предоставляет технологию XDTO, которая позволяет валидировать входящие и исходящие данные, передаваемые в формате XML.
HTTP сервисы же основаны практически на голом HTTP, и эта технология ресурсно-ориентированная. Нет описания, нет проверки типов, нет проверки входящих и исходящих данных — есть только заголовки, параметры и тело запроса. И исторически используется формат данных JSON.
Логично, что WEB-сервисы потенциально сложнее в реализации, потенциально используют больший объем передаваемых данных и дают потенциально большую вычислительную нагрузку.
О форматах данных
Примерно так выглядит XML:
Это, кстати, хороший формат, позволяющий закодировать практически любые данные. А его мощь обеспечивает возможность создания шаблонов XML — XSD-схем, что описывают формат и допустимые типы данных.
Именно поэтому его используют различного рода госорганы.
А так выглядит JSON — формат немного попроще:
Здесь есть основные типы данных: это объекты, формируемые фигурными скобками, массивы, формируемые квадратными скобками, и значение, которое формируется в виде текста.
Данные для HTTP-сервиса передаются в виде запроса HTTP, схематично изображенного ниже:
Он состоит из строки запроса, из заголовка запроса, который представляет собой ключ и значение, также есть пустая строка и тело запроса в виде обычного текста. В теле запроса можно передавать любые данные, в том числе и двоичные, предварительно закодировав их в base64.
Так выглядит строка запроса в HTTP сервисе:
Сервис HTTP ресурсно-ориентирован. Конечные точки, к которым мы можем обращаться, являются ресурсами: они представлены именами существительными. На схеме это элементы строки orders и status, обозначающие соответственно ресурсы «Заказ» и «Статус заказа». Действия над ресурсами выполняются методами HTTP, базовыми из которых являются: get (получить ресурс), post (добавить ресурс), put (обновить ресурс), delete (удалить ресурс). Количество методов HTTP ограничено, действия над ресурсами тоже. Помимо указанных методов есть еще несколько дополнительных, но используются они значительно реже.
Также имеет место понятие коллекции: несколько ресурсов одного типа, из которых можно выбрать один по идентификатору.
Про проектирование
Теперь мы поделимся той болью, которую мы пережили при проектировании API с клиентами и партнерами. И теми шагами, которые необходимо предпринять, чтобы эту боль в будущем чуть-чуть уменьшить.
При создании API предполагается, что пользоваться им будем не только мы, но и партнеры, и пользоваться достаточно долгое время. Здесь не обойтись без тщательного и взвешенного проектирования. Каждый момент должен быть учтен.
Вспоминаем, что HTTP сервис — это у нас, в первую очередь, ресурсы. А ресурсы — это имена существительные: вот таких элементов, как /GetOrders или /orders/add, где в качестве ресурсов явно указываются глаголы действия, быть не должно. В качестве действий у нас должны выступать методы HTTP (get, post, delete).
Правильное проектирование обычно идет по иерархии: коллекция, элемент, ресурс. И вот здесь мы специально отобразили один интересный момент, связанный с особенностями ресурсной иерархии. Например, к заказу у нас прикрепляются накладные. Есть заказ, есть накладные, которые выдаются по этому заказу (одна или несколько). К этим накладным мы можем дать доступ и как к отдельному ресурсу /invoices, и как к ресурсу в составе заказа — когда накладная сделана на основе заказа /orders/
Для проектирования рекомендуется элементы, ресурсы и действия сводить в таблицу, где в строках располагаются ресурсы, а в столбцах — методы HTTP. На пересечениях строк и столбцов — описание, что должно выполняться в данном случае. Пример таблицы:
Благодаря этому мы понимаем, какое действие у нас происходит в случае применения каждого из методов HTTP к соответствующему ресурсу, а также можем легко расширять набор ресурсов и действий над ними.
Про документацию
Если первый по важности пункт — это проектирование, второй — обязательно документация. HTTP протокол, HTTP сервисы не имеют описания, как это сделано в WEB сервисах. Поэтому документацию необходимо создавать, вести и обязательно поддерживать. Тем более, что ей пользуемся не только мы, но и партнеры.
В самом начале мы «забивали» на документацию, а когда партнеры спрашивали, каково предназначение того или иного метода, и что он в итоге принимает и возвращает — приходилось лезть в код. Теперь же мы просто говорим: посмотрите документацию, там все есть.
Документацию мы рекомендуем вести в таком виде:
Вот пример документации. Заголовок, ответ, пример, описание полей данных:
Будь мужиком! Пиши логи!
На первых порах логи пишем всегда и везде. При получении запроса от нашего партнера — пишем в журнал все данные запроса, включая тело. При формировании ответа в критически важных участках кода примечания пишем в лог. При передаче запроса партнеру также пишем его в лог. Когда отправляем партнеру ответ, пишем в лог. Когда мы сами обращаемся к партнеру, пишем в лог. Ну, и при сбое, вы уже поняли, что мы делаем.
Разделяй код и властвуй над ним
Еще один очень важный момент при проектировании, при разработке таких систем — это разделение методов обработки самого HTTP запроса и методов обработки данных, которые являются методами бизнес-логики. Сначала мы делаем обработку самого HTTP запроса, расшифровываем заголовки, тело запроса и результаты передаем в процедуры обработки данных, в другой модуль — модуль бизнес-логики. Для формирование тела запроса и запроса партнеру имеет смысл использовать отдельные общие методы, включающие в себя автоматический вызов функций логирования. И, естественно, мы должны выполнять начальный контроль данных, потому что, в отличие от WEB сервисов, контроль данных у нас не производится.
На примере этого кода продемонстрировано использование указанных выше правил:
В данном случае метод выполняет получение прайса от партнера. При получении производится запись запроса в лог с указанием имени сервиса. Затем выполняется разбор запроса, подготовка данных и формирование ответа на запрос.
Разбор запроса включает в себя чтение и подготовку всех параметров запроса, проверку обязательных параметров и валидацию их корректности.
После подготовки данных вызывается модуль бизнес-логики, где происходит обработка данных. Результат обработки возвращается в виде структуры, после чего происходит формирование тела ответа.
Ну и тем, кто дочитал до конца, автор этой статьи предлагает свою демонстрационную базу: он выполнил все указанные принципы, перенес код из работающей системы и делится с вами безвозмездно (то есть даром).