Прошлая часть: Форматы сообщений часть 1. JSON и типы данных.
Доброго дня. Давненько ничего не выкладывал, т.к. завалили работой. Но вот дописал вторую часть. Поехали.
В этой части не буду философствовать на тему «зачем тестировщику знать форматы сообщений и типы данных», а просто напомню выводы на эту тему из прошлой главы. Знать форматы сообщений и типы данных необходимо по следующим причинам:
- Для понимания «как клиент и сервер обмениваются запросами и ответами?» нужно сначала понять «из чего запросы и ответы в принципе состоят?».
- Для локализации проблем на стороне клиента необходимо понимать «что клиент вообще отправил и сделал ли он это в соответствии с требованиям?»
- Вы не всегда будете находиться в ситуации, когда у вас будет web-интерфейс для отправки запросов на сервер. Иногда вам придется эмулировать «клиент» внешней системы и составлять запрос вручную. А иногда вы будете находиться в ситуации, когда web-интерфейс еще не готов, но взаимодействие с сервером уже можно тестировать – и снова вам придется составлять запрос вручную.
- У вас должна быть банальная техническая грамотность, чтобы взаимодействовать с остальными членами команды на одном языке.
Многое в этой главе будет содержать отсылки к предыдущей главе про JSON, так что советую ознакомиться с ней, если пропустили - Форматы сообщений часть 1. JSON и типы данных.. Теперь ближе к сути вопроса.
XML
Аббревиатура XML расшифровывается как «eXtensible Markup Language» или в переводе на русский «Расширяемый Разметочный Язык». Сама задумка у формата XML аналогична задумке формата JSON– передавать данные, которые должны соответствовать определенной структуре. Но, как в том анекдоте – «Есть один нюанс…».
Сам формат XML, разумеется, отличается от JSON – было бы странно иметь 2 одинаковых формата, но с разными названиями. Формат XML при построении документа оперирует так называемыми «тэгами».
Тег – это часть документа, обозначающая границы какого-либо элемента. Каждый тег, обычно представлен в виде пары из открывающего и закрывающего тега, например:
Все теги начинаются с открывающейся угловой скобки и заканчиваются закрывающей угловой скобкой. Закрывающий тег дополнительно имеет знак слэша после открывающейся фигурной скобки. Значение тега является чувствительным к регистру, т.е. тег <Фамилия> и тег <ФАМИЛИЯ> — это два разных тега.
Еще одно отличие от JSON заключается в том, что даже значения с типом «объект» передаются внутри тегов.
В прошлой главе мы обсуждали приложение по созданию списка друзей. В качестве примера мы оставим это же приложение и сформируем XMLсообщение, которое будет передавать аналогичные данные, которые передавались при помощи JSON’а. Выглядеть оно будет следующим образом:
Не думаю, что в данном случае надо писать подробно что «для каждого поля есть открывающийся и закрывающийся тег» и аналогичные вещи уровня капитана-очевидности. Давайте разберем важные моменты, которые концептуально отличают XML от JSON:
- Само тело сообщения имеет тег с каким-то названием, в нашем примере это <message>, когда у родительского JSON объекта тело сообщения начинается просто с кавычки.
- Аналогичным образом отличается каждый элемент массива commonFriendsList – для каждого элемента массива есть тег <friendItem>, обозначающий границы каждого из элементов массива.
- Значение тега <birthDay>, в данном случае, передается не с типом «строка», а с типом «дата», который отсутствует в JSON (этот момент разберем чуть ниже).
- Значение <surname/> в данном случае передано как null, но это не точно. Варианта передачи «пустой строки» или передачи null в XML два – либо открывающимся и закрывающимся тегом с пустым значением, либо одним тегом со слэшом на конце (как в нашем примере). Причем что именно вы передали «null или строку» определяется XSD схемой.
На этом, в целом, отличия и закончились. Пункты 3 и 4 отличий могут показаться пугающими, но можете успокоиться и выдохнуть – в современных компаниях вы чаще будете видеть JSON формат, а не XML. Но в общих чертах вы должны себе представлять правила XML документов – чисто «на всякий случай».
Типы данных в XML
Снова вспоминаем форматы данных, которые проходили в теме про JSON формат. Там упоминались следующие типы данных:
- String (строка)
- Boolean (логическое значение)
- Number (число)
- Null (ничего)
- Array (массив)
- Object (объект)
В XML всё немного сложнее (ну вы только гляньте на саму структуру сообщения – она как бы намекает, что вам и не должно быть легко). Давайте начнем с того, что есть несколько версий так называемой XML Schema, которая трактует правила оформления XML документов. В зависимости от того какая из схем будет использоваться – будут действовать те или иные правила обработки документа. Я за основу взял схему из первого попавшегося в интернете конвертера XML -> XSD - http://www.w3.org/2001/XMLSchema-instance
Тип данных «строка» или «string».
Тут без изменений. Тип данных string обозначает строку переменной длины.
Тип данных «логическое значение» или «boolean».
Аналогично без изменений. Логическое значение может быть представлено значениями true (истина) или false (ложь)
Тип данных «нул» или «null».
Тут уже идет зависимость от XSD схемы. В указанной мной схеме такой тип данных как null отсутствует, но идеологически этот тип данных никуда не пропадает. Просто теги вида <tag></tag>, <tag/> или отсутствующий тег будет преобразовываться при помощи кода разработчика в значение null на сервере.
Тип данных «число», а точнее: byte, short, int, long, float, double и т.д.
Вот тут начинаются программистские «заморочки». Если в JSON нам хватало типа number, чтобы обозначить число – то в XML вам необходимо указать какое именно число вам надо.
Byte, short, int, long – это целочисленные типы данных, т.е. использующиеся для чисел в которых отсутствует дробная часть, условно 100 целых и ничего после запятой.
Float и double – это типы данных для чисел с плавающей точкой, которые могут использоваться, например, для обозначения числа 100.034123.
Разницу между категориями целочисленных и нецелочисленных типов данных вы можете прочитать в интернете – данная статья не совсем про это.
Тип данных «массив» или «array», и «объект» или «object».
Как таковой тип данных массив или объект в XML также отсутствует явно, но присутствует идеологически. Такие типы данных называются «сложный тип» или complexType. Комплексный тип данных в XML обозначает, что значение тега не удалось выразить в виде более простого типа данных.
Тип данных «дата» или «date», и «дата и время» или «dateTime».
Да-да, всё было бы легко, если б не было так сложно. В XML формате есть типы данных предназначенные для передачи даты или даты и времени. Если вы будете передавать дату в одном формате – XSD схема распознает ее как дату, если в другом – как строку. Аналогично с датой и временем. Примеры:
- 1972-01-01 – это дата для формата XML (т.к. она передается по формату yyyy-MM-dd).
- 01-01-1972 – это строка для формата XML (т.к. она передается НЕ по формату yyyy-MM-dd).
- 2002-05-30T09:00:00 – это дата и время для формата XML(т.к. она передается по формату yyyy-MM-dd’T’HH:mm:ss).
- 05-30-2002T09:00:00 – это строка для формата XML (т.к. она передается НЕ по формату yyyy-MM-dd’T’HH:mm:ss).
Если вы начинаете нервничать – напоминаю «…в современных компаниях вы чаще будете видеть JSON формат, а не XML». Также не лишним будет отметить, что несмотря на то, что в п.2 передана не «дата», а в п.4 не «дата и время», а строки – если сервер будет ждать именно строку, то для него не будет проблемой преобразовать такие строки в дату или дату и время. Поэтому при работе с датами и временем всё же советую чаще обращаться к требованиям, чтобы узнать необходимый формат.
Что такое XSD или «Как автоматически проверять формат XML сообщения»
Для описания структуры XML документов используется XSD (или по-другому XML Schema).
XSD - это файлы с расширением .xsd, которые описывают названия элементов, общую структуру данных и ожидаемые типы данных у того или иного сообщения.
На картинке ниже изображен пример XML схемы для сообщения, которое мы рассматривали выше.
А на следующей картинке изображен пример соответствия между тэгами XML сообщения и тэгами XML схемы:
Плюсы и минусы использования XSD аналогичны JSON схеме.
Основные плюсы использования XSD:
- На основании XSD сервер может отбраковывать не валидные сообщения «на входе», то есть до начала исполнения бизнес-логики.
- При интеграционном взаимодействии со сторонними системами XSD может выступать в роли «контракта». Если вы используете предоставленную коллегами XSD для валидации входящих сообщений от коллег, то в случае несоответствия входящего сообщения XML-схеме проблема будет явно на стороне коллег (что даст вам индульгенцию на указание пальцем в сторону коллег).
Но рука об руку с этими плюсами идут и минусы:
- Любое изменение формата сообщения должно будет приводить к изменению XML -схемы.
- Если XSD используется при интеграционном взаимодействии – необходимо будет дополнительно синхронизироваться с коллегами по добавлению / изменению обязательных полей (а не всегда будет ситуация, что конкретно вашей системе нужна вся информация из сообщения).
- При наличии хорошей серверной валидации (аналогичных проверок на серверной стороне) XML-схема практически перестанет приносить плюсы, зато минусы никуда не пропадут.
Следующая часть: Что такое интерфейс и что такое API
Поддержать или поблагодарить можете:
Лайком;
Комментарием;
Подпиской на канал;
