ЧТО ТАКОЕ MINOCCURS

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

Если вы тестируете API, то должны знать про два основных формата передачи данных:

Сегодня я расскажу вам про XML.

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.

Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!

См также:
Что такое API — общее знакомство с API
Что такое JSON — второй популярный формат
Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

Так что давайте разберемся, как он выглядит, как его читать, и как ломать! Да-да, а куда же без этого? Надо ведь выяснить, как отреагирует система на кривой формат присланных данных.


ЧТО ТАКОЕ MINOCCURS

Элемент sequence определяет, что дочерние элементы должны появляться в последовательности. Каждый дочерний элемент может использоваться от 0 до бесконечного числа раз.

Синтаксис элемента

(Знак ? указывает на то, что элемент может появляться ноль или один раз, знак * указывает на то, что элемент может появляться ноль, один или больше раз внутри элемента sequence.)

Атрибуты элемента

Пример №1
Следующий пример демонстрирует декларацию элемента “personinfo”, который должен содержать пять дочерних элементов “firstname”, “lastname”, “address”, “city” и “country”:

Пример №2
Следующий пример демонстрирует декларацию элемента “pets”, который должен содержать 0 или больше дочерних элементов “dog” и “cat”:

Мы можем контролировать, каким образом элементы должны использоваться в XML документах. Это позволяют сделать индикаторы.

Всего существует семь индикаторов:

Индикаторы очередности

Индикаторы очередности, как ясно из названия, используются для определения очередности появления элементов в XML документе.

Индикаторы частотности

Индикаторы частотности используются для того, чтобы определить то, как часто элементы могут появляться в XML документах.

Примечание: Для всех “порядковых” и “групповых” индикаторов (any, all, choice, sequence, group name и group reference) значением по умолчанию для maxOccurs и minOccurs является 1.

В приведенном выше примере указывается, что элемент “child_name” в элементе “person” может использоваться минимум один раз (значение по умолчанию для индикатора minOccurs – 1) и максимум 10 раз.

В приведенном выше примере указывается, что элемент “child_name” в элементе “person” может использоваться минимум 0 раз и максимум 10 раз.

Совет: Чтобы разрешить использовать какой-то элемент неограниченное число раз, используется выражение maxOccurs=”unbounded”.

XML файл “Myfamily.xml”:

Приведенный XML файл содержит корневой элемент “persons”. Внутри этого корневого элемента у нас есть три элемента “person”. Каждый элемент “person” должен содержать элемент “full_name” и может содержать до 5 элементов “child_name”.

А вот его файл схемы “family.xsd”:

Индикаторы группирования

Индикаторы группирования используются для определения связанных наборов элементов.

Группы элементов определяются при помощи декларации group следующим образом:

Внутри такой декларации необходимо определять элемент all, choice или sequence. В следующем примере определяется группа с именем “persongroup”, которая определяет группу элементов, которые должны появляться точно в указанном порядке:

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

Группы атрибутов определяются при помощи декларации attributeGroup:

В следующем примере определяется группа атрибутов с именем “personattrgroup”:

После того как группа атрибутов была определена, вы можете использовать ее в других определениях:

Время на прочтение

XSD — это язык описания структуры XML документа. Его также называют XML Schema. При использовании XML Schema XML-парсер может проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных. Многие так или иначе сталкивались с процедурой полной валидации, обеспечивающей соответствие документа заданной схеме или сообщающей о возможных ошибках. В данной статье речь пойдет о частичной валидации, кроме вышеописанного, позволяющей конструировать валидные документы «на лету». Мы разберемся, какие возможности может предоставить такой подход и способы его реализации.

Основная цель

Зачем вообще может понадобиться конструировать документ, обладающий заданными свойствами, и какими свойствами мы можем управлять? На первый вопрос ответ практически очевиден; большинство документов не являются просто текстом, а наделены некоторой семантикой. X ML решает вопрос синтаксического представления, а схема – частично решает вопрос семантического значения. Благодаря соответствию документа схеме, можно выполнять над ним набор предопределенных действий, допустимых для целого класса валидных документов, будь то представление в другом формате, экспорт значимой части информации для конкретной задачи, импорт новой информации с учетом глобальных ограничений. Наиболее часто применяемый механизм в таком случае – это XSLT преобразование, смысл которого можно проиллюстрировать следующей диаграммой:


ЧТО ТАКОЕ MINOCCURS

На второй вопрос полностью ответит спецификация схемы, а мы остановимся лишь на самых важных пунктах, которые дают представление о возможностях схем. Итак, схема позволяет:

Часто возникает желание модифицировать документ, уже отвечающий выбранной схеме, таким образом, чтобы он не потерял валидность. Здесь речь идет и о автоматических модификациях, например добавление веб-агентами (агрегаторами) информации в документ или модифицирующие запросы в XML-базу данных, так и о ручной модификации, скажем, в визуальном XML-редакторе. Операция полной валидации для больших документов может занимать существенное время, десятки секунд и более, что в целом препятствует использованию подхода «атомарное изменение – проверка – отказ/разрешение». А для визуальных редакторов хотелось бы еще больше – иметь возможность не только проверить атомарное действие, а предложить все допустимые по схеме варианты модификации конкретного узла. Однако, хорошие XML-редакторы умеют это делать, и мы попробуем разобраться каким образом у них это получается.

Необходимая информация о XML схеме

Вообще говоря, правило Unique Particle Attribution (UPA) не является жестким требованием к структуре XML схем, а только крайне желательной рекомендацией и часть используемых схем ему не соответствует. Рассмотрим простейший пример, иллюстрирующий нарушение правила однозначности определения частиц.

Построение валидатора

Для начала определим элементарные изменения структуры, которые мы и будем проверять на корректность:

Теперь опишем модель содержимого сложного типа схемы:

1. Построение недетерминированного конечного автомата (NFA) с заданным конечным состоянием S по заданной частице:
   a. Установим начальное состояние n на S;

b. Если MaxOccurs частицы равен бесконечности (inf):
     • Добавим новое промежуточное состояние t; получаемое из преобразования терма в NFA (случай 2); добавим эпсилон-ребра из t в n и из n в S:

c. Если MaxOccurs частицы – число m:
     • Строим цепочку из (MaxOccurs-MinOccurs) преобразований терма, начиная из конечного состояния S, добавляя эпсилон-ребро из промежуточного состояния на каждом шаге в конечное состояние S;
Например, для MaxOccurs=4 и MinOccurs=2 получаем следующий автомат:

d. Достраиваем minOccurs копий преобразования терма от нового начального состояния n, до начального состояния, полученного на предыдущих шагах.

2. Построение недетерминированного конечного автомата с заданным принимающим состоянием S по заданному терму:
   a. Если терм – шаблон (any):
     • Создаем новое состояние b, и соединяем его с S ребром, помеченным типом терма, возвращаем b;

b. Если терм – описание элемента:
     • Создаем новое состояние b, затем для каждого элемента группы подстановки создаем ребро из b в S, помеченное типом элемента и возвращаем b;

c. Если терм – выбор (choice):
     • Создаем новое состояние b, для каждого элемента выбора создаем автомат (случай 1) и соединяем его эпсилон-ребрами с состоянием b и состоянием S. Возвращаем b;

d. Если терм – последовательность (sequence):
     • Для каждого элемента выбора создаем автомат (случай 1) и соединяем полученные автоматы в обратном порядке, начиная с состояния S, и возвращаем первое состояние в цепочке;

Это происходит когда существуют два исходящих ребра из одной вершины, такие что:

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

Осталось решить последнюю задачу – выбор нужного конечного автомата при валидации операции над заданным элементом дерева. С этим нам поможет структура привязки типов валидации (PSVI, Post-Schema-Validation Infoset), порождаемая почти любым (например, MSXML или libxml) полным валидатором. Для любого элемента дерева она указывает на соответствующий ему тип в описании схемы – в точности тот, по которому мы порождали нужный автомат.


ЧТО ТАКОЕ MINOCCURS

В нашем случае реализация структуры PSVI представляется ссылкой на тип схемы для каждого элемента дерева.

Операции MOVE и REMOVE не меняют тип операнда (поэтому не требуют изменения структуры PSVI), а операция ADD вместе с добавлением элемента x, потребует добавления в структуру PSVI типа x. Таким образом, вместе с изменением структуры мы меняем и информационное множество привязки типов валидации, решая задачу частичной валидации и поддерживая дерево PSVI без вызова внешнего валидатора.

Сравнение результатов

Вообще говоря, непосредственного сравнения не будет – ведь мы описали надстройку, решающую частную задачу (операции ADD/REMOVE/MOVE) в частном случае (соответствие UPA), но хочется показать что в этом случае она дает существенный прирост скорости, относительно попытки использовать полную валидацию. В качестве эталонного валидатора, генерирующего PSVI был выбран MSXML6, поэтому и сравнивать будем с его временем работы.

Таким образом, мы получили вполне допустимое среднее время ожидания проверки, позволяющее реализовать механизм Drag’n’Drop «на лету» в визуальном редакторе, и обеспечивающее хорошее количество запросов в секунду для возможной XML-базы данных.

Ссылки

Показатели группы используются для определения связанных наборов элементов.

Элемент группы

групп элементов определяются с декларацией группы, как это:

Вы должны определить все, выбор, или последовательность элементов внутри декларации группы. Следующий пример определяет группу под названием , который определяет группу элементов , которые должны произойти в точной последовательности:

После того, как вы определили группу, вы можете ссылаться на нее в другом определении, как это:

Группы атрибутов

Атрибут группы определяются с декларацией attributeGroup, как это:

Следующий пример определяет атрибут группу под названием :

После того как вы определили группы атрибутов, вы можете ссылаться на нее в другом определении, как это:

Как устроен XML

Возьмем пример из документации подсказок Дадаты по ФИО:

И разберемся, что означает эта запись.


ЧТО ТАКОЕ MINOCCURS

Теги

В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки:

Текст внутри угловых скобок — название тега.
Тега всегда два:


ЧТО ТАКОЕ MINOCCURS

Ой, ну ладно, подловили! Не всегда. Бывают еще пустые элементы, у них один тег и открывающий, и закрывающий одновременно. Но об этом чуть позже!

С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается». Это как дорожные знаки:

— На въезде в город написано его название: Москва
— На выезде написано то же самое название, но перечеркнутое:

* Пример с дорожными знаками я когда-то давно прочитала в статье Яндекса, только ссылку уже не помню. А пример отличный!


ЧТО ТАКОЕ MINOCCURS

Корневой элемент

В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. В случае REST API документ — это запрос, который отправляет система. Или ответ, который она получает.

Чтобы обозначить этот запрос, нам нужен корневой элемент. В подсказках корневой элемент — «req».


ЧТО ТАКОЕ MINOCCURS

Он мог бы называться по другому:

Да как угодно. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа — сам запрос. Те параметры, которые мы передаем внешней системе. Разумеется, они тоже будут в тегах, но уже в обычных, а не корневых.

Значение элемента

Значение элемента хранится между открывающим и закрывающим тегами. Это может быть число, строка, или даже вложенные теги!

Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.


ЧТО ТАКОЕ MINOCCURS

Внутри — значение запроса.


ЧТО ТАКОЕ MINOCCURS

Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):


ЧТО ТАКОЕ MINOCCURS

Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.

Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».


ЧТО ТАКОЕ MINOCCURS

Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.


ЧТО ТАКОЕ MINOCCURS

См также:
Что тестировщику надо знать про панель разработчика — подробнее о том, как использовать консоль.

Но оба значения идут

кавычек. В XML нам нет нужды брать строковое значение в кавычки (а вот в JSON это сделать придется).

У элемента могут быть атрибуты — один или несколько. Их мы указываем внутри отрывающегося тега после названия тега через пробел в виде

название_атрибута = «значение атрибута»


ЧТО ТАКОЕ MINOCCURS

Зачем это нужно? Из атрибутов принимающая API-запрос система понимает, что такое ей вообще пришло.

Например, мы делаем поиск по системе, ищем клиентов с именем Олег. Отправляем простой запрос:

А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:

Давайте разберем эту запись. У нас есть основной элемент party.


ЧТО ТАКОЕ MINOCCURS

У него есть 3 атрибута:


ЧТО ТАКОЕ MINOCCURS

Внутри party есть элементы field.


ЧТО ТАКОЕ MINOCCURS

У элементов field есть атрибут name. Значение атрибута — название поля: имя, дата рождения, тип или номер телефона. Так мы понимаем, что скрывается под конкретным field.


ЧТО ТАКОЕ MINOCCURS

Это удобно с точки зрения поддержки, когда у вас коробочный продукт и 10+ заказчиков. У каждого заказчика будет свой набор полей: у кого-то в системе есть ИНН, у кого-то нету, одному важна дата рождения, другому нет, и т.д.

Но, несмотря на разницу моделей, у всех заказчиков будет одна XSD-схема (которая описывает запрос и ответ):

— есть элемент party;
— у него есть элементы field;
— у каждого элемента field есть атрибут name, в котором хранится название поля.

А вот конкретные названия полей уже можно не описывать в XSD. Их уже «смотрите в ТЗ». Конечно, когда заказчик один или вы делаете ПО для себя или «вообще для всех», удобнее использовать именованные поля — то есть «говорящие» теги. Какие плюшки у этого подхода:

— При чтении XSD сразу видны реальные поля. Т З может устареть, а код будет актуален.
— Запрос легко дернуть вручную в SOAP Ui — он сразу создаст все нужные поля, нужно только значениями заполнить. Это удобно тестировщику + заказчик иногда так тестирует, ему тоже хорошо.

В общем, любой подход имеет право на существование. Надо смотреть по проекту, что будет удобнее именно вам. У меня в примере неговорящие названия элементов — все как один будут field. А вот по атрибутам уже можно понять, что это такое.

Помимо элементов field в party есть элемент attribute. Не путайте xml-нотацию и бизнес-прочтение:


ЧТО ТАКОЕ MINOCCURS

У элемента attribute есть атрибуты:


ЧТО ТАКОЕ MINOCCURS

А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.

XML пролог

Иногда вверху XML документа можно увидеть что-то похожее:

Эта строка называется XML прологом. Она показывает версию XML, который используется в документе, а также кодировку. Пролог необязателен, если его нет — это ок. Но если он есть, то это должна быть первая строка XML документа.

UTF-8 — кодировка XML документов по умолчанию.

XSD-схема

Фишка в том, что проверку по схеме можно делегировать машине. И разработчику даже не надо расписывать каждую проверку. Достаточно сказать «вот схема, проверяй по ней».

Если мы создаем SOAP-метод, то указываем в схеме:

Поэтому зачем запускать сложную процедуру, если запрос заведом «плохой»? И выдавать ошибку через 5 минут, а не сразу? Валидация по схеме помогает быстро отсеять явно невалидные запросы, не нагружая систему.


ЧТО ТАКОЕ MINOCCURS

Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!


ЧТО ТАКОЕ MINOCCURS

А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?

Да-да, в идеале у нас есть подробное ТЗ, где всё хорошо описано. Но увы и ах, такое есть не всегда. Иногда ТЗ просто нет, а иногда оно устарело. А вот схема не устареет, потому что обновляется при обновлении кода. И она как раз помогает понять, как запрос должен выглядеть.


ЧТО ТАКОЕ MINOCCURS

Итого, как используется схема при разработке SOAP API:

Попробуем написать для него схему. В запросе должны быть 3 элемента (email, name, password) с типом «string» (строка). Пишем:

А в WSDl сервиса она записана еще проще:

Конечно, в схеме могут быть не только строковые элементы. Это могут быть числа, даты, boolean-значения и даже какие-то свои типы:

А еще в схеме можно ссылаться на другую схему, что упрощает написание кода — можно переиспользовать схемы для разных задач.

См также:
XSD — умный XML — полезная статья с хабра
Язык определения схем XSD — тут удобные таблички со значениями, которые можно использовать
Язык описания схем XSD (XML-Schema)
Пример XML схемы в учебнике
Официальный сайт w3.org

Составляем свой запрос

Ок, теперь мы знаем, как «прочитать» запрос для API-метода в формате XML. Но как его составить по ТЗ? Давайте попробуем. Смотрим в документацию. И вот почему я даю пример из Дадаты — там классная документация!


ЧТО ТАКОЕ MINOCCURS

Что, если я хочу, чтобы мне вернулись только женские ФИО, начинающиеся на «Ан»? Берем наш исходный пример:

В первую очередь меняем сам запрос. Теперь это уже не «Виктор Иван», а «Ан»:

Далее смотрим в ТЗ. Как вернуть только женские подсказки? Есть специальный параметр — gender. Название параметра — это название тегов. А внутри уже ставим пол. « Женский» по английски будет FEMALE, в документации также. Итого получили:

Ненужное можно удалить. Если нас не волнует количество подсказок, параметр count выкидываем. Ведь, согласно документации, он необязательный. Получили запрос:

Вот и все! Взяли за основу пример, поменяли одно значение, один параметр добавили, один удалили. Не так уж и сложно. Особенно, когда есть подробное ТЗ и пример )))

Показатели Встречаемость

Показатели Встречаемость используются для определения, как часто может произойти элемент.

Note: Для всех и показателей (любой, все, выбор, последовательность, название группы, и группа справки) значение по умолчанию для MaxOccurs и MinOccurs 1.

MaxOccurs Индикатор

индикатор определяет максимальное количество раз может возникнуть элемент:

Приведенный выше пример показывает , что элемент может происходить как минимум один раз (значение по умолчанию для MinOccurs 1) и не более десяти раз в элемента.

MinOccurs Индикатор

индикатор определяет минимальное число раз может произойти элемент:

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

Tip: Чтобы разрешить элемент появляться неограниченное число раз, используйте MaxOccurs = “неограниченную” заявление:

A working example:

XML файл , который называется :

Файл XML выше содержит корневой элемент с именем . Внутри этого корневого элемента мы определили три элементы. Каждый элемент должен содержать элемент и может содержать до пяти элементов.

Вот файл схемы :

Есть семь показателей:

Индикаторы Заказать

Индикаторы заказа используются для определения порядка элементов.

Все Индикатор

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

Note: При использовании индикатор вы можете установить индикатор 0 или 1 , а индикатор может быть установлен только в 1 ( и описаны ниже).

Выбор индикатора

индикатор указывает , что может происходить либо один дочерний элемент или другой:

Индикатор чередования фаз

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

Well Formed XML

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. X ML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:


ЧТО ТАКОЕ MINOCCURS

Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

См также:
Сообщения об ошибках — тоже документация, тестируйте их! — зачем тестировать сообщения об ошибках

Есть корневой элемент

Нельзя просто положить рядышком 2 XML и полагать, что «система сама разберется, что это два запроса, а не один». Не разберется. Потому что не должна.

И если у вас будет лежать несколько тегов подряд без общего родителя — это плохой xml, не well formed. Всегда должен быть корневой элемент:

Что мы делаем для тестирования этого условия? Правильно, удаляем из нашего запроса корневые теги!

У каждого элемента есть закрывающийся тег

Тут все просто — если тег где-то открылся, он должен где-то закрыться. Хотите сломать? Удалите закрывающийся тег любого элемента.

Но тут стоит заметить, что тег может быть один. Если элемент пустой, мы можем обойтись одним тегом, закрыв его в конце:

Это тоже самое, что передать в нем пустое значение


ЧТО ТАКОЕ MINOCCURS

Итого — если есть открывающийся тег, должен быть закрывающийся. Либо это будет один тег со слешом в конце.

Для тестирования удаляем в запросе любой закрывающийся тег.

Теги регистрозависимы

Как написали открывающий — также пишем и закрывающий. Т ОЧНО ТАК ЖЕ! А не так, как захотелось.

А вот для тестирования меняем регистр одной из частей. Такой XML будет невалидным

Правильная вложенность элементов

Элементы могут идти друг за другом


ЧТО ТАКОЕ MINOCCURS

Один элемент может быть вложен в другой


ЧТО ТАКОЕ MINOCCURS

Но накладываться друг на друга элементы НЕ могут!


ЧТО ТАКОЕ MINOCCURS

Атрибуты оформлены в кавычках

Даже если вы считаете атрибут числом, он будет в кавычках:

Для тестирования пробуем передать его без кавычек:

Итого

XML (eXtensible Markup Language) используется для хранения и передачи данных.

Передача данных — это запросы и ответы в API-методах. Если вы отправляете SOAP-запрос, вы априори работаете именно с этим форматом. Потому что SOAP передает данные только в XML. Если вы используете REST, то там возможны варианты — или XML, или JSON.

Хранение данных — это когда XML встречается внутри кода. Его легко понимает как машина, так и человек. В формате XML можно описывать какие-то правила, которые будут применяться к данным, или что-то еще.

Вот пример использования XML в коде open-source проекта folks. Я не знаю, что именно делает JacksonJsonProvider, но могу «прочитать» этот код — есть функционал, который мы будем использовать (featuresToEnable), и есть тот, что нам не нужен(featuresToDisable).

Формат XML подчиняется стандартам. Синтаксически некорректный запрос даже на сервер не уйдет, его еще клиент порежет. Сначала проверка на well formed, потом уже бизнес-логика.


ЧТО ТАКОЕ MINOCCURS

Если вы тестировщик, то при тестировании запросов в формате XML обязательно попробуйте нарушить каждое правило! Да, система должна уметь обрабатывать такие ошибки и возвращать адекватное сообщение об ошибке. Но далеко не всегда она это делает.

А если система публичная и возвращает пустой ответ на некорректный запрос — это плохо. Потому что разработчик другой системы налажает в запросе, а по пустому ответу даже не поймет, где именно. И будет приставать к поддержке: «Что же у меня не так?», кидая информацию по кусочкам и в виде скринов исходного кода. Оно вам надо? Нет? Тогда убедитесь, что система выдает понятное сообщение об ошибке!

Что такое XML
Учебник по XML
Изучаем XML. Эрик Рэй (книга по XML)
Заметки о XML и XLST

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *