Особенности и параметры протокола XML
Передача документов на языке XML является одним из самых распространенных и универсальных методов передачи данных через Интернет.
Протокол XML подразумевает обмен запросами на языке XML. Обмен информацией происходит через соединение TCP/IP по протоколу HTTP или HTTPS (HTTP over SSL) методом POST.
Для обмена информацией посылается XML-запрос вида: <xml_request name=″”>
Возможные значения поля name:
- name=″sms_send″ – запрос на отправку SMS
- name=″sms_status2″ – запрос на получение статуса ранее отправленных SMS
В ответ приходит отклик вида: <xml_result xml_name=″″ res=″″>
Возможные значения поля name:
- name=″sms_send″ – запрос на отправку SMS
- name=″sms_status2″ – запрос на получение статуса ранее отправленных SMS
Возможные значения поля res:
- res=″-xxxxx″ – обнаружена ошибка с кодом -xxxxx
Авторизация происходит передачей логина и пароля: <xml_user lgn=″″ pwd=″″/>
Преимущества:
- возможности расширения благодаря гибкости языка XML
- безопасность и сохранность данных, передаваемых по протоколу HTTPS методом POST
Входные параметры- Адрес обращения :
http://service.qtelecom.ru/public/http/z.php или https://service.qtelecom.ru/public/http/z.php - Формат входных данных :
Content-Type: application/x-www-form-urlencoded Content-Charset: UTF-8
- Тип авторизации : PLAIN (открытым текстом)
- Метод отправки запроса : POST
Отправка SMS сообщения и получение статусов ранее отправленных сообщений производятся отправкой XML-запроса определенной структуры.
В одном XML-запросе может быть отправлено до 250 SMS сообщений.
2.1 XML-запрос для отправки сообщенийКлиент отправляет XML-запрос на отправку сообщения (определить, что идет отправка SMS можно по полю name=″sms_send″)
<?xml version="1.0" encoding="UTF-8" ?>
<xml_request name="sms_send">
<xml_user lgn="" pwd=""/>
<sms sms_id="1" number="XXXXXXXXXXX" source_number="sender" ttl="10">text sms</sms>
<sms sms_id="2" number="XXXXXXXXXXX" source_number="" ttl="15">text sms</sms>
<sms sms_id="s_3" number="XXXXXXXXXXX" source_number="">text sms</sms>
</xml_request>Параметры запроса:
- sms_id – уникальный идентификатор SMS в системе клиента.
Строка длиной до 50 символов. На основе уникальности параметра sms_id проверяется дублирование запросов на отправку SMS. Если sms_id - number – телефонный номер получателя в международном формате или короткий номер. Строка длиной до 25 символов. Параметр не может быть пустым.
- source_number – номер отправителя. Строка длиной от 11 до 16 символов в зависимости от nипа (номер или текст). Параметр не может быть пустым.
- ttl – Время жизни сообщения в минутах. Необязательный параметр. Максимальное время, в течение которого сообщение должно быть доставлено на телефон. Если в течение этого времени доставка не возможна (например абонент не в зоне действия сети), сообщение не будет доставлено вовсе. Внимание, данная функция может не работает для некоторых направлений, например для CDMA телефонов.
Строка длиной до 50 символов. На основе уникальности параметра sms_id проверяется дублирование запросов на отправку SMS. Если sms_id
При успешном разборе XML-запроса в ответ придет сообщение вида:
<xml_result xml_name="sms_send" res="" >
<push sms_id="1" push_id="XXXX" res="0" number="XXXXXXXXXXX" sms_count=""/>
<push sms_id="2" push_id="XXXX" res="0" number="XXXXXXXXXXX" sms_count=""/>
<push sms_id="3" res="" description=""/>
</xml_result>Параметры ответа:
- push_id – уникальный идентификатор SMS в системе ESME
- sms_id – уникальный внутренний идентификатор SMS в системе клиента
- res=0 – SMS было отправлено успешно
- res – ″-xxxx″ — код ошибки, возникшей при отправке конкретного SMS
- description – описание ошибки, возникшей при отправке конкретного SMS
- number – номер телефона получателя SMS
- sms_count – количество SMS, из которых состоит одно набранное сообщение
Если в результате разбора XML-запроса возникли ошибки, придет сообщение вида:
<xml_result res=″-XXXX″ description=″″/>
Параметры ответа:
- res – код ошибки XML-запроса или его обработки
- description – описание ошибки
2 XML-запрос для получения статуса ранее переданных сообщенийКлиент отправляет XML-запрос на получение статуса переданных сообщений (определить, что идет получение статуса SMS можно по полю name=″sms_status2″)
<?xml version="1.0" encoding="UTF-8" ?> <xml_request name="sms_status2" > <xml_user lgn="" pwd=""/> <sms push_id=""/> <sms push_id=""/> <sms push_id=""/> <sms push_id=""/> </xml_request>
Параметры запроса:
- push_id – идентификатор ранее переданного SMS в системе ESME
При успешном разборе XML-запроса в ответ придет сообщение вида:
< xml_result name="sms_status2" res="" > < sms push_id="" status="" number="XXXXXXXXXXX" delivery_date="" delivery_time="" description="" /> < sms push_id="" status="" number="XXXXXXXXXXX" delivery_date="" delivery_time="" description="" /> < sms push_id="" status="" number="XXXXXXXXXXX" delivery_date="" delivery_time="" description="" /> </xml_result>
Параметры ответа:
- push_id – идентификатор ранее переданного SMS в системе ESME
- status – код статуса доставки
- number – номер телефона, на который было отправлено сообщение с указанным push_id
- delivery_time — время доставки SMS. Строка вида «hh:mm:ss»
- delivery_date – дата доставки SMS. Строка вида «dd.mm.yyyy»
- description – описание статуса. Строка.
Строка вида «hh:mm:ss»Если в результате разбора XML-запроса возникли ошибки, придет сообщение вида:
<xml_result res="-XXXX" description=""/>
Параметры ответа:
- res – код ошибки XML-запроса или его обработки
- description – описание ошибки
Для предотвращения ошибок при разборе XML-запросов и ответов, символы в тексте сообщения, которые используются как служебные в языке XML, необходимо заменять. Замена производится в запросах по таблице слева направо, а в ответах производится обратная замена справа налево.
| Специальный символ | Замена |
|---|---|
| < | < |
| > | > |
| » | " |
| ‘ | ' |
| & | & |
Статусы доставки ранее отправленных SMSПри выполнении запроса на получение статусов доставки ранее переданных сообщений <sms_status2> возвращаются коды, представленные в таблице.
| Статус | Описание | Расшифровка статуса |
|---|---|---|
| -1004 | Push to SMSC failed | SMS не доставлена по одной из следующих причин: — абонент находится вне зоны действия сети; — номер не обслуживается оператором связи; — недостаточно средств на счете; — для абонента заблокирован/не поддерживается прием SMS; — переполнена очередь входящих SMS на телефоне абонента; либо по другим причинам, связанным с невозможностью доставки. |
| -1 | Bad submit_id | Указан не существующий push_id сообщения |
| 1 | Push request queued | SMS помещена в очередь на отправку |
| 2 | Request redirected to SMSC/MMSC | SMS передана оператору связи и ожидает доставку |
| 4 | Content delivery confirmed | SMS доставлена |
Коды ошибок, возникающих при обработке запросовПри обработке XML-запроса могут возникать ошибки, код которых возвращаются в атрибуте <res>, а описание в атрибуте <description> ответа. Не следует путать эти коды ошибок со статусами доставки SMS!
Система выдает описания ошибок, возникших как при разборе XML-запроса в целом, так и для каждого отдельного переданного сообщения.
5.1 Ошибки, относящиеся к XML-запросу в целомКод и описание ошибки при разборе XML-запроса передается параметрами res и description в теге <xml_result>. Если возникли ошибки при разборе XML-запроса, она относится ко всем сообщениям данного запроса и ни одно из переданных в этом запросе сообщений не будет доставлено.
5.2 Ошибки, относящиеся к передаче отдельных сообщений запроса Код и описание ошибки при отправке каждого конкретного SMS передается параметрами res и description в теге <push>.
Код и описание ошибки в теге <push> относится только к сообщению с данным <push_id>. Все сообщения запроса при этом будут доставлены или не доставлены независимо друг от друга.
XML API — Документация Devino Documentation latest
XML API — Документация Devino Documentation latestОбзор
Документация включает описание API для отправки SMS-сообщений через платформу Devino Telecom с примерами запросов.
API включает в себя возможность как транзакционных, так и массовых рассылок, получение подробной статистики по рассылкам.
Документ предназначен для разработчиков, которые хотят добавить возможность взаимодействия с Сервисом отправки SMS-сообщений на страницы своих сайтов или в свои приложения.
Общение с сервисом осуществляется при помощи отправки XML запросов в кодировке UTF-8 на заданный адрес сервиса по протоколу HTTPS методом POST, проверка типа контента не осуществляется.
Каждый запрос может состоять из отправляемых сообщений и (или) запросов для получения статусов и (или) запросов для получения входящих сообщений.
Предупреждение
Внимание! Для использования данного вида интеграции необходимо обратиться к своему менеджеру, либо в техническую поддержку [email protected] для настройки доступа.
Сервис доступен по адресу:
https://xmlapi.devinotele.com
Отправка сообщений
https://xmlapi.devinotele.com/Send.ashx
Отправка сообщений осуществляется в соответствии с очередностью по получению сообщений и временем отправки.
Пример запроса:
<?xml version="1.0" encoding="utf-8" ?>
<package login="login" password="123456">
<message>
<default sender="SMSINFO"/>
<msg recipient="+79021234567" sender="SMSINFO" date_beg="2008-12-27T15:55" date_end="2008-12-28T15:55" type="0">text</msg>
<msg recipient="+79021234568">text</msg>
</message>
</package>
| Параметр | Тип данных | Обязательный | Описание |
|---|---|---|---|
| Default | Нет | Тег, в котором определяются общие атрибуты, указываемые для всех
отправляемых сообщений. Если какой-либо атрибут указан в сообщении,
то атрибут данного тега игнорируется | |
| msg | да | Тег сообщения, в качестве параметра указывается текст отправляемого сообщения | |
| id | integer | Нет | Пользовательский числовой идентификатор сообщения |
| recipient | varchar(21) | Да | Номер телефона. Пример: 79031234567, +79031234567 |
| sender | varchar(11) | Да | Адрес отправителя |
| date_beg | datetime, ISO8601 | Нет | Дата отправки сообщения, указывается для отложенной отправки сообщений. |
| date_end | datetime, ISO8601 | Нет | Дата, после которой сообщение теряет актуальность и если оно еще не было отправлено абоненту, отправляться не будет. |
| url | varchar(100) | Да * | Ссылка для создания wap-push сообщения |
| type | integer | Да | Тип сообщения: 0-обычное сообщение 1-flash сообщение 2-wap-push сообщение |
*Поле обязательное для отправки wap-push сообщений
На полученный запрос сервис возвращает в виде параметра статус сообщения, а в атрибутах идентификаторы, присвоенные сообщениям.
Пример ответа:
<?xml version="1.0" encoding="utf-8" ?>
<package>
<message>
<msg sms_id="0" sms_count="1">201</msg>
<msg sms_id="1234568" sms_count="1">1</msg>
</message>
</package>
| Параметр | Тип данных | Описание |
|---|---|---|
| msg | Тег сообщения, в качестве параметра возвращается код статуса | |
| id | integer | Пользовательский числовой идентификатор сообщения, необязательный атрибут, возвращается при указании данного атрибута в запросе |
| sms_id | integer | Числовой идентификатор сообщения, присвоенный шлюзом |
| sms_count | integer | Реальное количество SMS к отправке |
Запрос статусов сообщений
https://xmlapi.devinotele.com/Statistics.
ashx
Статусы сообщений содержат информацию о текущем состоянии сообщения, регулярно обновляются и могут быть запрошены пользователем в любое время. Статусы можно запрашивать за последние 3 календарных дня. Максимальное количество ID в запросе 1000.
Пример запроса:
<?xml version="1.0" encoding="utf-8" ?>
<package login="login" password="123456">
<status>
<msg/>
<msg sms_id="1234568"/>
</status>
</package>
| Параметр | Тип данных | Обязательный | Описание |
|---|---|---|---|
| msg | Нет | Тег сообщения, для которого происходит запрос статуса | |
| id | integer | Нет * | Пользовательский числовой идентификатор сообщения, возвращается при указании данного атрибута в запросе |
| sms_id | integer | Да * | Числовой идентификатор сообщения, присвоенный шлюзом |
*Можно указать любой из этих параметров
В ответ на запрос возвращается XML документ содержащий статусы для запрошенных сообщений, либо соответствующие коды ошибок.
Пример ответа:
<?xml version="1.0" encoding="utf-8" ?>
<package>
<status>
<msg sms_id="0" sms_count="1" date_completed="2009-03-14T15:27:03">102</msg>
<msg sms_id="1234568" sms_count="1">1</msg>
</status>
</package>
| Параметр | Тип данных | Описание |
|---|---|---|
| msg | Тег сообщения, для которого происходит запрос статуса, в качестве параметра возвращается код статуса | |
| id | integer | Пользовательский числовой идентификатор сообщения, возвращается при указании данного атрибута в запросе |
| sms_id | integer | Числовой идентификатор сообщения, присвоенный шлюзом |
| sms_count | integer | Реальное количество SMS к отправке |
| date_completed | datetime, ISO8601 | Дата присвоения финального статуса |
Коды статусов документа
При отправке XML документа могут возвращаться следующие коды ошибок:
| Код | HTTP Status | Расшифровка |
|---|---|---|
| ERR_UNKNOWN | 200 | Неизвестная ошибка |
| ERR_FORMAT | 201 | Неправильный формат документа |
| ERR_AUTHORIZATION | 202 | Ошибка авторизации |
Пример ответа:
<?xml version="1.
0" encoding="utf-8" ?>
<package>
<error>201</error>
</package>
Коды статусов сообщений
Данные коды используются при возврате статусов сообщений.
Статусы сообщений:
| Код | HTTP Status | Расшифровка |
|---|---|---|
| SCHEDULED | 100 | Запланировано |
| ENROUTE | 101 | В очереди |
| DELIVERED | 102 | Доставлено |
| EXPIRED | 103 | Просрорчено |
| DELETED | 104 | Просрочено |
| UNDELIVERABLE | 105 | Не доставлено |
| ACCEPTED | 106 | Принято |
| UNKNOWN | 107 | Ошибка |
| REJECTED | 108 | Отклонено |
| DISCARDED | 109 | Отклонено |
Статусы ошибок:
| Код | HTTP Status | Расшифровка |
|---|---|---|
| ERR_UNKNOWN | 200 | Неизвестная ошибка |
| ERR_ID | 201 | Неправильный ID сообщения |
| ERR_SENDER | 202 | Неправильный адрес отправителя |
| ERR_RECIPIENT | 203 | Неправильный номер получателя |
| ERR_LENGTH | 204 | Слишком длинное или пустое сообщение |
| ERR_USER_DISABLE | 205 | Пользователь отключен |
| ERR_BILLING | 206 | Ошибка биллинга |
| ERR_OVERLIMIT | 207 | Превышение лимита выделенных сообщений |
Read the Docs v: latest
- Versions
- latest
- Downloads
- html
- epub
- On Read the Docs
- Project Home
- Builds
Free document hosting provided by Read the Docs.
XML-протокол
XML-протоколРабочие проекты (обсуждение разработчиков) События/пабы Закладки
Цель XML Протокол предназначен для разработки технологий, позволяющих двум или более одноранговым узлам общаться в распределенной среде, используя XML в качестве своей инкапсуляции язык. Решения, разработанные в рамках этой деятельности, позволяют использовать многоуровневую архитектуру на вершина расширяемого и простого формата обмена сообщениями, который обеспечивает надежность, простота, возможность повторного использования и интероперабельность. XML Заявление об активности протокола объясняет работу W3C по этой теме более подробно. подробности.
Первая рабочая группа в этом упражнении — XML Рабочая группа протокола.
Первоначальная цель рабочей группы по протоколу XML
разработать структуру для систем обмена сообщениями на основе XML, которая включает в себя
указание формата конверта сообщения и метода сериализации данных,
в основном, но не исключительно, для RPC-приложений и в соответствии с
вышеуказанные принципы.
Более подробная информация содержится в Уставе.
- Версия SOAP 1.2, часть 0: введение, часть 1: структура обмена сообщениями, часть 2: рабочие проекты дополнений опубликованы 17 декабря 2001 г.
- Сценарии использования протокола XML Рабочий проект опубликован 17 декабря 2001 г.
- XML-протокол (XMLP) Требование Документ
- Абстрактная модель протокола XML
- Сценарии использования протокола XML
- SOAP, версия 1.2, часть 0: основы
- SOAP, версия 1.2, часть 1: обмен сообщениями Каркас
- SOAP, версия 1.2, часть 2: дополнения
Обсуждение разработчиков
Технические вопросы обсуждаются на [email protected] (Архив).
Подписаться на
xml-dist-app, отправлять почту на
[email protected]
с Тема: подписка . Для большего
информацию см. в W3C
страница списка рассылки.
Публикации
- Октябрь 2001 г. : SOAP версии 1.2
Часть 1: Рабочий проект платформы обмена сообщениями
- Октябрь 2001 г. : SOAP версии 1.2 Часть 2: Дополнения, рабочий проект
- Июль 2001 г. : SOAP версии 1.2 работает Проект
- июль 2001 г. : Абстрактная модель протокола XML Рабочий проект
- Март 2001 г. : Требования протокола XML Рабочий проект
- Декабрь 2000 : XML Рабочий проект требований протокола
- Сентябрь 2000 г. : Рабочая группа протокола XML Устав
: SOAP версии 1.2
Часть 1: Рабочий проект платформы обмена сообщениямиСобытия
В результате повышенного интереса к XML-протоколам W3C и другие недавно организовал несколько мероприятий по различным протоколам XML, связанным с деятельность в том числе
- 11-12 апреля 2001 г. : Семинар по веб-сервисам в Сан-Хосе, Калифорния.
- Сентябрь 2000 : Создание рабочего протокола XML Группа
- 15-19 мая 2000 г. : W3C организует
панель по протоколам XML на WWW9 в Амстердаме
- Май 2000 г.: W3C признает отправку SOAP/1.1 как Примечание W3C: простой доступ к объектам Протокол (SOAP) 1.1. Заявители: Ariba, Inc., Commerce One, Inc., Compaq Computer Corporation, DevelopMentor, Inc., Hewlett Packard Company, International Business Machines. Corporation, IONA Technologies, Lotus Development Corporation, Microsoft Corporation, SAP AG, UserLand Software Inc
- Май 2000 г.: W3C предоставляет начальный сравнение различных инициатив, уже представленных на рынке
- Март 2000: Майкл Кондри, Sun, организует B2BXML BOF в IETF 47 в Аделаида, Австралия, 26-31
- , февраль/март 2000 г.: W3C организует XML-протоколы. BOF в XTech 2000
- , февраль 2000 г.: W3C предоставляет временную план для XML протокол работы
- Декабрь 1999 г. : W3C создает
[email protected]
список рассылки для обсуждения вопросов, связанных с протоколом XML.
: W3C организует
панель по протоколам XML на WWW9 в Амстердаме
: W3C создает
В этой области предпринимается множество усилий, от уровня транспорта до документов высокого уровня с длительным жизненным циклом, большинство из них уже составлено в Матрица протокола XML.
- Матрица протокола XML
Ив Лафон
$Id: Overview.html,v 1.29 2001/12/18 22:34:52 ylafon Exp $
XML-протокол (XMLP)
Протокол XML (XMLP) предоставляет простые протоколы, которые можно повсеместно развертывать и легко программировать с помощью языков сценариев, инструментов XML, интерактивных инструментов веб-разработки и т. д. Целью является создание многоуровневой системы, которая будет напрямую удовлетворять потребности приложений с простыми интерфейсами (например, getStockQuote, validateCreditCard), который можно постепенно расширять для обеспечения безопасности, масштабируемости и надежности, необходимых для более сложных интерфейсов приложений.
В частности, рабочей группе по протоколу XML поручено разработать следующие четыре компонента:
- Конверт для инкапсуляции XML-данных, которые должны передаваться интероперабельным образом, обеспечивающим распределенную расширяемость.
- Соглашение о содержимом конверта при использовании для приложений RPC (удаленный вызов процедур). Протокольные аспекты этого следует тесно координировать с IETF и прилагать усилия для использования любой работы, которую они выполняют, подробности см. ниже.
- Механизм сериализации данных, представляющих несинтаксические модели данных, такие как графы объектов и ориентированные помеченные графы, на основе типы данных схемы XML.
- Механизм использования транспорта HTTP в контексте протокола XML. Это не означает, что HTTP является единственным транспортным механизмом, который можно использовать для разработанных технологий, или что поддержка HTTP-транспорта является обязательной. Этот компонент просто учитывает тот факт, что HTTP-транспорт, как ожидается, будет широко использоваться, и поэтому эта рабочая группа должна рассмотреть его. Будет осуществляться координация с Инженерной группой Интернета (IETF),
см. Блоки
Расширяемый протокол обмена (BEEP).
Будет осуществляться координация с Инженерной группой Интернета (IETF),
см. Блоки
Расширяемый протокол обмена (BEEP).Кроме того, работа, выполненная этой рабочей группой, должна отвечать следующим двум общим требованиям:
- Оболочка и механизмы сериализации, разработанные рабочей группой, не могут исключать какую-либо модель программирования или предполагать какой-либо конкретный способ связи между одноранговыми узлами. .
- В центре внимания должны быть простота и модульность, а также должна поддерживаться та расширяемость, которая действительно наблюдается в Интернете. В частности, он должен поддерживать распределенную расширяемость, когда у взаимодействующих сторон нет априорное знание друг друга.
Рабочая группа должна начать с разработки документа с требованиями, а затем оценить технические решения, предложенные в представлении SOAP/1.1, на соответствие этим требованиям. Если в ходе этого процесса рабочая группа находит решения, которые, по соглашению, являются улучшениями по сравнению с решениями, предложенными в SOAP 1.
1, следует использовать эти улучшенные решения.
Организация: W3C
Дополнительная информация: XMLP страница на сайте W3C
Статьи по теме для протокола XML (XMLP)
Дополнительные сведения по текущей теме: Протокол XML (XMLP)
- Блоки расширяемого протокола обмена (BEEP)
- Асинхронный протокол службы приложений (ASAP) для SOAP
- Спецификация службы сообщений (MSS)
- Нотация объектов JavaScript (JSON)
- Передача репрезентативного состояния (REST)
- Деловое сообщение RosettaNet
- МЫЛО
- Распределенный обмен данными через Интернет (WDDX)
- Адресация веб-служб (WS-адресация)
- События веб-служб (WS-Eventing)
- Уведомление веб-служб (WSN)
- Надежность веб-служб (WS-надежность)
- Надежный обмен сообщениями веб-служб (WS-ReliableMessaging)
Автор
Дуглас К.
Барри
Директор
Барри энд Ассошиэйтс, Инк.
Вы можете использовать этот материал для своей работы или занятий. Политика перепечатки. Не забудьте проверить меню слева для других статей, доступных на этом сайте.Руководство для опытного менеджера
Дуглас К. Барри также является автором книги, в которой веб-службы, сервис-ориентированная архитектура и облачные вычисления объясняются простым для понимания и нетехническим языком.
Веб-службы, сервис-ориентированные архитектуры и облачные вычисления: руководство для опытного менеджера (второе издание)
Дуглас К. Барри с Дэвидом Диком
Это руководство для сообразительного менеджера, который хочет извлечь выгоду из волны изменений, происходящих с веб-сервисами, сервисно-ориентированной архитектурой и — в последнее время — облачными вычислениями.