Проектирование API

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

Протокол HTTP был предложен в 1991 году Тимом Берненсом-Ли. В 1996 году был сформирован RFC 1945 и разработаны первые клиенты, которые работали по этому протоколу. В 1999 году было обновление протокола (RFC 2068), где уже были добавлены сессии и множество других улучшений (HTTP 1.1).

Вторая версия HTTP (HTTP 2.0) вышла в 2015 году (RFC 7540). Из важного добавилась возможность работать с push-уведомлениями и много других полезных изменений.

Теперь мы немного поговорим про модели OSI и TCP/IP. Модель OSI более новая, нежели TCP/IP. Она построена на базе TCP/IP и разработана, чтобы более четко декомпозировать разработку приложений на определенных уровнях.

Слои модели OSI

Физический слой - передача битов по сети и их конвертация в цифровую информацию (оптоволокно, витая пара, wifi).

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

Сетевой уровень - адресация запросов и маршрутизация через транспортные узлы.

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

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

Уровень представлений - шифрование и дешифрование. Передача формата символов клиенту.

Уровень приложений - реализация. Тут мы уже можем пользоваться реальным приложением (смотреть видео, слушать аудио и так далее).

REST APIREST - Representation State Transfer. Это архитектурный принцип построения распределенных систем. На текущий момент один из самых популярных подходов в разработке API. По сути это способ брать состояние ресурсов и строить так называемые RESTful сервисы.

Для построения RESTful сервиса наша система должна быть разработана на клиент-серверной архитектуре. Все сервисы должны быть stateless, то есть они не должны хранить состояние о запросе клиента, и любой запрос, который будет сделан клиентом к любому из инстансов вашего сервиса, должен вернуть одни и те же результаты. Все запросы, которые сделаны к вашему сервису, должны быть помечены как кэшируемые и некэшируемые.

Также сервисы могут делить зону ответственности и работать по слоям согласно конкретному бизнес-процессу.

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

Мой канал - https://t.me/carbonka (Продолжение в следующем посте).