Pull to refresh
375
0

Разрабатываю API более 10 лет

Send message

Книга завершена [SDK & UI-библиотеки] Вычисляемые свойства. Заключение

Level of difficulty Medium
Reading time 3 min
Views 1.3K

Это главы 47-48 раздела «SDK и UI-библиотеки» моей книги «API». На этом второе издание книги завершено, все шесть разделов готовы. Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Вернёмся к одной из проблем, описанных в главе «Проблемы встраивания UI-компонентов»: наличие множественных линий наследования усложняет кастомизация компонентов, поскольку подразумевает, что они могут наследовать важные свойства по любой из вертикалей.

Пусть у нас имеется кнопка, которая получает одно и то же свойство iconUrl по двум вертикалям — из данных [т.е., в случае нашего примера, из результатов поиска предложений] и из настроек отображения:

Читать далее
Total votes 9: ↑8 and ↓1 +7
Comments 2

[SDK и UI-библиотеки] Разделяемые ресурсы и асинхронные блокировки

Level of difficulty Medium
Reading time 4 min
Views 585

Это глава 46 раздела «SDK и UI-библиотеки» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Другой важный паттерн, который мы должны рассмотреть — это доступ к общим ресурсам. Предположим, что в нашем учебном приложении открытие экрана предложения стало требовать выполнения дополнительного запроса к серверу и, таким образом, стало асинхронным. Модифицируем код OfferPanelComponent:

Читать далее
Total votes 1: ↑1 and ↓0 +1
Comments 0

[SDK и UI-библиотеки] Backend-Driven UI

Level of difficulty Medium
Reading time 3 min
Views 1.7K

Это глава 46 раздела «SDK и UI-библиотеки» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

В предыдущей главе мы обсудили, каким образом можно упростить разработку сложных компонентов с использованием паттерна «модель». Другой способ обойти сложность «переброса мостов» между несколькими предметными областями, которые нам приходится сводить в рамках одного UI-компонента — это убрать одну из них. Как правило, речь идёт о бизнес-логике: мы можем разработать компоненты полностью абстрактными, и скрыть все трансляции UI-событий в полезные действия вне контроля разработчика.

В такой парадигме код поиска предложений выглядел бы так:

Читать далее
Total votes 5: ↑4 and ↓1 +3
Comments 8

[SDK и UI-библиотеки] MV*-фреймворки

Level of difficulty Hard
Reading time 6 min
Views 940

Это глава 44 раздела «SDK и UI-библиотеки» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Очевидным способом сделать менее сложными многослойные схемы, подобные описанным в предыдущей главе, является ограничение возможных путей взаимодействия между компонентами. Как мы описывали в главе «Слабая связность», мы могли бы упростить код, если бы разрешили нижележащим субкомпонентам напрямую вызывать методы вышестоящих сущностей. Например, так:

Читать далее
Total votes 3: ↑3 and ↓0 +3
Comments 0

[SDK и UI-библиотеки] Декомпозиция UI-компонентов

Level of difficulty Hard
Reading time 12 min
Views 890

Это глава 44 раздела «SDK и UI-библиотеки» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Перейдём к более предметному разговору и попробуем объяснить, почему требование возможности замены одной из подсистем компонента приводит к кратному усложнению интерфейсов. Продолжим рассматривать пример компонента SearchBox из предыдущей главы. Напомним, что мы выделили следующие факторы, осложняющие проектирование API визуальных компонентов:

Читать далее
Total votes 10: ↑10 and ↓0 +10
Comments 0

[SDK и UI-библиотеки] Проблемы встраивания UI-компонентов

Level of difficulty Hard
Reading time 6 min
Views 510

Введение в состав SDK UI-компонентов обогащает и так не самую простую конструкцию из клиент-серверного API и клиентской библиотеки дополнительным измерением: теперь с вашим API взаимодействуют одновременно и разработчики (которые написали код приложения), и пользователи (которые используют приложение). Хотя это изменение на первый взгляд может показаться не очень значительным, с точки зрения дизайна API добавление конечного пользователя — огромная проблема, которая требует на порядок более глубокой и качественной проработки дизайна программных интерфейсов по сравнению с «чистым» клиент-серверным API. Попробуем объяснить, почему так происходит, на конкретном примере.

Читать далее
Rating 0
Comments 0

[SDK и UI-библиотеки] Введение. SDK: Проблемы и решения

Level of difficulty Hard
Reading time 11 min
Views 1.3K

Аббревиатура «SDK» («Software Development Kit»), как и многие из обсуждавшихся ранее терминов, не имеет конкретного значения. Считается, что SDK отличается от API тем, что помимо программных интерфейсов содержит и готовые инструменты для работы с ними. Определение это, конечно, лукавое, поскольку почти любая технология сегодня идёт в комплекте со своим набором инструментов.

Тем не менее, у термина SDK есть и более узкое значение, в котором он часто используется: это клиентская библиотека, которая предоставляет высокоуровневый (обычно, нативный) интерфейс для работы с некоторой нижележащей платформой (и в частности с клиент-серверным API). Чаще всего речь идёт о библиотеках для мобильных ОС или веб браузеров, которые работают поверх HTTP API сервиса общего назначения.

Читать далее
Rating 0
Comments 5

[HTTP API & REST] Работа с ошибками в HTTP API. Заключительные положения и общие рекомендации

Level of difficulty Hard
Reading time 12 min
Views 7.7K

Это главы 39 и 40 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Читать далее
Total votes 5: ↑4 and ↓1 +3
Comments 0

[HTTP API & REST] Разработка номенклатуры URL ресурсов. CRUD-операции

Level of difficulty Hard
Reading time 11 min
Views 6.8K

Это глава 38 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Как мы уже отмечали в предыдущих главах, стандарты HTTP и URL, а также принципы REST, не предписывают определённой семантики значимым компонентам URL (в частности, частям path и парам ключ‑значение в query). Правила организации URL в HTTP API существуют только для читабельности кода и удобства разработчика. Что, впрочем, совершенно не означает, что они неважны: напротив, URL в HTTP API являются средством выразить уровни абстракции и области ответственности объектов. Правильный дизайн иерархии сущностей в API должен быть отражён в правильном дизайне номенклатуры URL.

NB: отсутствие строгих правил естественным образом привело к тому, что многие разработчики их просто придумали сами для себя. Некоторые наиболее распространённые стихийные практики, например, требование использовать в URL только существительные, в советах по разработке HTTP API в Интернете часто выдаются за стандарты или требования REST, которыми они не являются. Тем не менее, демонстративное игнорирование таких самопровозглашённых правил тоже не лучший подход для провайдера API, поскольку он увеличивает шансы быть неверно понятым.

Традиционно частям URL приписывается следующая семантика:

Читать далее
Total votes 7: ↑7 and ↓0 +7
Comments 6

[HTTP API & REST] Организация HTTP API согласно принципам REST

Level of difficulty Hard
Reading time 10 min
Views 7.5K

Это глава 37 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Перейдём теперь к конкретике: что конкретно означает «следовать семантике протокола» и «разрабатывать приложение в соответствии с архитектурным стилем REST». Напомним, речь идёт о следующих принципах: операции должны быть stateless; данные должны размечаться как кэшируемые или некэшируемые; интерфейсы взаимодействия между компонентами должны быть стандартизированы; сетевые системы многослойны.

Эти принципы мы должны применить к протоколу HTTP, соблюдая дух и букву стандарта: URL операции должен идентифицировать ресурс, к которому применяется действие, и быть ключом кэширования для GET и ключом идемпотентности — для PUT и DELETE; HTTP‑глаголы должны использоваться в соответствии с их семантикой; свойства операции (безопасность, кэшируемость, идемпотентность, а также симметрия GET / PUT / DELETE‑методов), заголовки запросов и ответов, статус‑коды ответов должны соответствовать спецификации.

Читать далее
Total votes 8: ↑8 and ↓0 +8
Comments 18

[HTTP API & REST] Преимущества и недостатки HTTP API

Level of difficulty Hard
Reading time 8 min
Views 7.1K

Это главы 36 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

После трёх вступительных глав с прояснением основных терминов и понятий (такова, увы, цена популярности технологии) у читателя может возникнуть резонный вопрос — а почему вообще существует такая дихотомия: какие-то API полагаются на стандартную семантику HTTP, а какие-то полностью от неё отказываются в пользу новоизобретённых стандартов. Например, если мы посмотрим на формат ответа в JSON-RPC, то мы обнаружим, что он легко мог бы быть заменён на стандартные средства протокола HTTP. Вместо

Читать далее
Total votes 3: ↑3 and ↓0 +3
Comments 7

[HTTP API & REST] Терминология. Мифология REST. Составляющие HTTP-запроса

Reading time 19 min
Views 15K

Вопросы организации HTTP API — к большому сожалению, одни из самых «холиварных». Будучи одной из самых популярных и притом весьма непростых в понимании технологий (ввиду большого по объёму и фрагментированного на отдельные RFC стандарта), спецификация HTTP обречена быть плохо понятой и превратно истолкованной миллионами разработчиков и многими тысячами учебных пособий.

Читать далее
Total votes 6: ↑6 and ↓0 +6
Comments 18

[Паттерны API] Частичные обновления. Деградация и предсказуемость

Level of difficulty Hard
Reading time 9 min
Views 3.6K

Это главы 24 и 25 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Раздел «Паттерны API» на этом завершён. Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Читать далее
Total votes 5: ↑5 and ↓0 +5
Comments 3

[Паттерны API] Атомарность массовых изменений

Level of difficulty Hard
Reading time 6 min
Views 2.5K

Это глава 23 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Вернёмся теперь от webhook-ов обратно к разработке API прямого вызова. Дизайн эндпойнта orders/bulk-status-change, описанный в предыдущей главе, ставит перед нами интересный вопрос: что делать, если наш бэкенд часть изменений смог обработать, а часть — нет?

Пусть партнёр уведомляет нас об изменении статусов двух заказов:

Читать далее
Total votes 6: ↑4 and ↓2 +2
Comments 0

[Паттерны API] Мультиплексирование сообщений. Асинхронная обработка событий

Level of difficulty Hard
Reading time 4 min
Views 2.9K

Это глава 22 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Одно из неприятных ограничений почти всех перечисленных в предыдущей главе технологий — это относительно невысокий размер сообщения. Наиболее проблематичная ситуация с push-уведомлениями: Google Firebase Messaging на момент написания настоящей главы разрешал сообщения не более 4000 байт. Но и в серверной разработке ограничения заметны: например, Amazon SQS лимитирует размер сообщения 256 килобайтами. При разработке webhook-ов вы рискуете быстро упереться в размеры тел сообщений, выставленных на веб-серверах партнёров (например, в nginx по умолчанию разрешены тела запросов не более одного мегабайта). Это приводит нас к необходимости сделать два технических выбора:

Читать далее
Rating 0
Comments 0

[Паттерны API] Двунаправленные потоки данных. Push и poll-модели

Level of difficulty Hard
Reading time 13 min
Views 6.6K

Это глава 21 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

В предыдущей главе мы рассмотрели следующий кейс: партнёр получает информацию о новых событиях, произошедших в системе, периодически опрашивая эндпойнт, поддерживающий отдачу упорядоченных списков.

Читать далее
Total votes 4: ↑4 and ↓0 +4
Comments 2

[Паттерны API] Списки и организация доступа к ним

Level of difficulty Hard
Reading time 11 min
Views 7.6K

Это глава 20 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

В предыдущей главе мы пришли вот к такому интерфейсу, позволяющему минимизировать коллизии при создании заказов:

Читать далее
Total votes 9: ↑8 and ↓1 +7
Comments 0

[Паттерны API] Асинхронность и управление временем

Level of difficulty Hard
Reading time 7 min
Views 7.3K

Это глава 19 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Продолжим рассматривать предыдущий пример. Пусть на старте приложение получает какое-то состояние системы, возможно, не самое актуальное. От чего ещё зависит вероятность коллизий и как мы можем её снизить?

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

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

Читать далее
Total votes 7: ↑6 and ↓1 +5
Comments 0

[Паттерны API] Слабая консистентность

Level of difficulty Hard
Reading time 7 min
Views 4.1K

Это глава 18 моей книги «API». Описанный в предыдущей главе подход фактически представляет собой размен производительности API на «нормальный» (т. е. ожидаемый) фон ошибок при работе с ним путём изоляции компонента, отвечающего за строгую консистентность и управление параллелизмом внутри системы. Тем не менее, его пропускная способность всё равно ограничена, и снизить её мы можем единственным образом — убрав строгую консистентность из внешнего API, что даст возможность осуществлять чтение состояния системы из реплик:

Читать далее
Rating 0
Comments 8

[Паттерны API] Введение. Аутентификация партнёров и авторизация вызовов API. Стратегии синхронизации

Level of difficulty Hard
Reading time 11 min
Views 6.7K

Этим постом я начинаю публикацию v2 моей книги «API». v2 будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Читать далее
Total votes 8: ↑7 and ↓1 +6
Comments 2

Information

Rating
Does not participate
Location
Россия
Registered
Activity