Глава 3: Форматы данных
Брайан Кукси - опубликовано 22 апреля 2014
Итак, мы узнали, что HTTP является основой API-интерфейсов в интернете и что для их использования нам необходимо знать, как работает HTTP. В этой главе мы исследуем, какие данные предоставляют API, как они форматируются и как HTTP делает это возможным.
Представление данных
При обмене данными с людьми возможности отображения информации ограничиваются только человеческой фантазией. Вспомните пиццерию из предыдущей главы — как она может оформить своё меню? Например, как текстовый список или маркированный список, может быть серией фотографий с подписями или только набором фотографий, на которые показывают посетители, чтобы оформить заказ.
Хорошо продуманный формат помогает целевой аудитории понимать информацию.
Тот же принцип применяется при обмене данными между компьютерами. Один компьютер должен поместить данные в формат, понятный для другого. Обычно это какой-то текстовый формат.

Наиболее распространёнными форматами, встречающимися в современных API, являются JSON (JavaScript Object Notation, нотация объектов JavaScript) и XML (Extensible Markup Language, расширяемый язык разметки) .
JSON
Многие новые API-интерфейсы приняли JSON в качестве формата, потому что он построен на популярном языке программирования Javascript, который повсеместно используется в интернете и применим как на фронте, так и на бэкенде веб-приложения или сервиса. JSON — это очень простой формат, состоящий из двух частей: ключей (keys) и значений (values). Ключи представляют собой свойство, атрибут описываемого объекта. Заказ пиццы может быть объектом. У него есть атрибуты (ключи), такие как тип корочки, начинка и статус заказа. У этих атрибутов есть соответствующие значения (толстое тесто, пепперони и «доставляется»).

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

{
    "crust": "original",
    "toppings": ["cheese", "pepperoni", "garlic"],
    "status": "cooking"
}
В приведенном выше примере JSON ключевыми словами являются слова слева: начинка, корочка и статус. Они говорят нам, какие атрибуты содержит заказ пиццы. Значения указаны в частях справа. Это фактические детали заказа.

Рисунок 1. Ключ и значение JSON

Если вы прочитаете строку слева направо, вы получите довольно естественное английское предложение. Взяв, к примеру, первую строчку, мы могли бы прочитать её как «корочка для этой пиццы оригинального стиля». Вторая строка также может быть прочитана — в JSON значение, которое начинается и заканчивается квадратными скобками ([]), представляет собой список значений. Итак, мы читаем вторую строку заказа как «начинки для этого заказа: сыр, пепперони и чеснок».

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

{
    "crust": "original",
    "toppings": ["cheese", "pepperoni", "garlic"],
    "status": "cooking",
    "customer": {
        "name": "Brian",
        "phone": "573-111-1111"
    }
}
В этой обновленной версии мы видим, что добавлен новый ключ «клиент». Значение этого ключа — это еще один набор ключей и значений, которые предоставляют подробную информацию о клиенте, разместившем заказ. Классный трюк, а?! Это называется Ассоциативным Массивом. Но не пугайтесь технического языка, ведь ассоциативный массив — это просто вложенный объект.
XML
XML существует с 1996 года. С возрастом он стал очень зрелым и мощным форматом данных. Как и JSON, XML предоставляет несколько простых строительных блоков, которые создатели API используют для структурирования своих данных. Основной блок называется
узлом (node).

Давайте посмотрим, как может выглядеть наш заказ пиццы в XML:

<order>
    <crust>original</crust>
    <toppings>
        <topping>cheese</topping>
        <topping>pepperoni</topping>
        <topping>garlic</topping>
    </toppings>
    <status>cooking</status>
</order>
XML всегда начинается с корневого узла, которым в нашем примере с пиццей является «заказ». Внутри заказа находятся ещё несколько «дочерних» узлов. Имя каждого узла сообщает нам атрибут заказа (как и ключ в JSON), а данные внутри представляют собой фактические детали (как и значение в JSON).

Рисунок 2. Узел и значение в XML

Вы также можете вывести предложения на английском языке, читая XML. Глядя на строчку с «корочкой», мы могли прочитать «корочка для пиццы оригинального стиля». Обратите внимание, как в XML каждый элемент в списке начинок обернут узлом. Как видите, формат XML требует гораздо больше текста для передачи, чем JSON.
Как форматы данных используются в HTTP
Теперь, когда мы изучили некоторые доступные форматы данных, нам нужно знать, как использовать их в HTTP. Для этого мы ещё раз поприветствуем одну из основ HTTP: заголовки. В главе 2 мы узнали, что заголовки — это список информации о запросе или ответе. Есть заголовок, указывающий, в каком формате находятся данные: Content-Type .

Когда клиент отправляет заголовок Content-Type в запросе, он сообщает серверу, что данные в теле запроса отформатированы
определённым способом. Если клиент хочет отправить серверу данные в формате JSON, он установит Content-Type на «application/json». Получив запрос и увидев этот Content-Type, сервер сначала проверит, понимает ли он этот формат, и, если да, он будет знать, как читать данные. Аналогичным образом, когда сервер отправляет клиенту ответ, он также устанавливает Content-Type, чтобы сообщить клиенту, как читать тело ответа.

Иногда клиент может общаться только в одном формате данных. Если сервер отправляет обратно что-либо, кроме этого формата, клиент откажется и выдаст ошибку. К счастью, на помощь приходит второй HTTP-заголовок. Клиент может установить заголовок Accept, чтобы сообщить серверу, какие форматы данных он может принимать. Если клиент может общаться только в формате JSON, он может установить для заголовка Accept значение «application/json». И тогда сервер будет отправлять ответы в формате JSON. Если сервер не поддерживает формат, запрашиваемый клиентом, он может отправить клиенту сообщение об ошибке, чтобы сообщить ему, что запрос не будет работать.

С помощью этих двух заголовков, Content-Type и Accept, клиент и сервер могут работать с форматами данных, которые они понимают и должны работать должным образом.

Рисунок 3. Заголовки форматов данных

Краткое содержание главы 3
В этой главе мы узнали, что для того, чтобы два компьютера могли общаться, они должны понимать передаваемый им формат данных. Мы познакомились с двумя распространенными форматами данных, используемыми в API: JSON и XML. Мы также узнали, что HTTP-заголовок Content-Type — это полезный способ указать, какой формат данных отправляется в запросе, а заголовок Accept определяет запрошенный формат для ответа.

Ключевые термины, которые мы узнали, были:
  • JSON: нотация объектов JavaScript
  • Объект: вещь или существительное (человек, заказ пиццы ...)
  • Ключ: атрибут объекта (цвет, начинка ...)
  • Значение: значение атрибута (синий, пепперони ...)
  • Ассоциативный массив: вложенный объект
  • XML: расширяемый язык разметки
Что дальше
В следующей главе мы узнаем, как два компьютера могут установить доверительные отношения с помощью аутентификации для передачи конфиденциальных данных, таких как сведения о клиентах или частный контент.