Проектирование Web API в 7 шагов

7stepsРазработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

Подробнее

Характеристики микросервисов, приложений и систем

Всем привет!

Сегодня хочу представить интересную презентацию Стефана Тилькова, со основателя и главного консультанта в innoQ. Стефан рассказывает об идее разделения больших систем на небольшие приложения, которые отвечают за разные аспекты системы. Сама идея не нова, но автор упирает на то, что основной причиной такого разделения должна быть изоляция. Благодаря границам приложений полученных таким образом, сложнее получить связанные модули, которые на самом деле должны быть независимыми. Тут еще можно вспомнить подход «domains boundary», для разделения доменных сущностей по областям применения, вместо того, чтобы создавать единую модель данных на всю большую организацию/процесс.

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

В презентации Стефан также рассказывает о том, что традиционные предположения о том, каким образом строить программные системы подвергаются сегодня тотальному пересмотру. Одно из таких предположений, что большая система должна иметь единое окружение, часто с однозначным соответствием между функциональными требованиями проекта и реализацией, что выливается в формулу «1 проект = 1 система». Хотя такое решение не всегда самое лучшее, оно получается очень жестким.

Рассматривая способ построения логических систем из малых частей, Тильков описывает три стиля:

  • Микросервисы – маленькие программы, каждая из которых работает сама по себе. Используют простые механизмы для общения и строятся вокруг нужд бизнеса.
  • Приложения – небольшие, отдельные, исполняемые программы, использующие модель «share nothing». Имеют много общего с микросервисами.
  • Самодостаточные системы – это крупные автономные программы, которые содержат и данные и логику. Контролируются одной командой. Не используют синхронные удаленные вызовы, могут предоставлять API.

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

Screenshot

Наиболее интересным параметром для Тилькова является количество модулей в системе, потому что это показывает степень декомпозиции большой системы.  Большие системы в этом плане проигрывают, но микросервисы сложнее в поддержке и оркестровке, тем самым увеличивая уровень сложности системы. В общем, нет какого-то одного правильного решения, «серебряной пули» и мы на конференции API & Backend хотели бы поднять дискуссию на эту тему. Если у вас есть интересные случаи из практики касающиеся типичных проблем для той или иной модели, пути решения этих проблем – мы ждем ваших историй.

 

Hard’n’Heavy!