Дизайнеру – о технологиях: API

Это шестой пост цикла "дизайнеру – о технологиях", в котором мы немножко повышаем уровень технической грамотности продуктовых дизайнеров и проектировщиков.

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

Что такое API

Наверняка, многие из вас хотя бы слышали, что скрывается за страшными словами Application Programming Interface. Да, это тоже интерфейс, но программный. По сути, API – это некий набор правил, по которым компоненты системы обмениваются информацией между собой. Например, так делает почти любое мобильное приложение и его сервер.

Состав API

Чтобы вам было проще разобраться, вот краткое (очень краткое) описание того, из чего состоит средний по больнице обмен данными между компонентами системы.

Форматы сообщений

Это то, как именно структурируются данные при обмене информацией между компонентами.

Форматов довольно много, но чаще всего используются два: XML и JSON. Страшные слова, на деле – всё просто.

Одни и те же данные в форматах XML и JSON.

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

Типы сообщений

Чаще всего их только два: запрос (request) и ответ (responce). Описываются они отдельно, что из себя представляет каждый – думаю, понятно.

Запросы могут быть разных типов, но, опять же, чаще всего используются только два: POST и GET. Если вы видели когда-нибудь непонятные слова в URL после знака вопроса (например, https://site.com/?utm_source=zen) – то это был именно GET. При отправке типа POST параметры прячутся внутрь сообщения, и их так просто не увидишь.

Ключевая разница между POST и GET-запросами.

Параметры

Это то самое мясо, которое передаётся от одного компонента другому. Состоят, как правило, из пары "ключ":"значение".

Например, в куске JSON это выглядит так:

"first_name": "Mike"

А в куске XML – вот так:

<first_name>Mike</first_name>

Ключ/значение в XML и JSON.

Форматы данных

Классический пример: пользователь в поле суммы ввёл буквы, а клиент (браузер) эту штуку не проверил – и в таком виде передал на сервер. Сервер слопал данные, попробовал сформировать счёт – и не смог к сумме добавить НДС. Он честно попробовал к слову "Вася" добавить 20% – и упал с ошибкой.

Или еще пример: в поле ввода названия произведения не указали максимальную длину, и сервер пытался сохранить в БД строку длиной с Байкало-Амурскую магистраль, тогда как база принимала максимум 255 символов. А всё потому, что те, кто проектировал сервис, не указали обязательный формат данных.

Форматов огромная тьма, я даже не буду пытаться их все перечислять. Просто знайте, что они есть – и делятся на логические, текстовые, числовые, форматы даты и времени, пространственные, составные (вроде массивов) - и еще кучу других, в зависимости от технологии.

Итог

Если вы проектируете какую-нибудь интеграцию, необходимо очень чётко понимать, как будут взаимодействовать компоненты – иначе может выясниться, что какие-то данные от внешней системы (или внутреннего компонента) просто невозможно получить.

Мне встречались проекты, где проектировщик не удосужился хотя бы базово пройтись по структуре данных – и понапридумывал некоторое количество полей, взять которые было банально неоткуда.

Больше статей на тему

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

• Вводная статья: зачем дизайнеру всё это.
• Фреймворки – что это такое и какие бывают.
• Коротко об управлении контентом: CMS и CMF.
• О технологиях мобильных приложений.
• Об обмене данными, синхронных и асинхронных запросах.
• Основы информационной безопасности в дизайне.
• Почему важно думать о SEO.

--

Все свои посты я аккумулирую в небольшом телеграм-канале, подписывайтесь.