API как абстракция

Когда речь заходит о программном обеспечении, API-интерфейсы буквально повсюду. Они идут рука об руку с одной из основополагающих концепций в информатике: абстракция. Абстракция — это всего лишь способ организации системы таки образом, чтобы сложные действия могли быть обработаны простым способом. Вот один из примеров абстракции: Amazon Dash Buttons -кнопочные печатные платы с питанием от аккумуляторов, которые вы можете использовать для заказа с Amazon. Вот как это выглядят:

Вы заказываете Dash Buttons из Amazon и используете приложение на своем смартфоне, чтобы связать их с вашей Wi-Fi сетью, учетной записью Amazon и продуктом, скажем, вашим любимым брендом бумажных полотенец. Затем, когда вы хотите заказать больше бумажных полотенец, вы просто нажимаете кнопку. Dash Button подключается к Интернету и отправляет сообщение для размещения заказа в вашей учетной записи. Через несколько дней к вашему порогу приходят бумажные полотенца.

 

Как и API, Dash Buttons — это невероятно простой интерфейс, который скрывает всевозможные сложности за кулисами. Идентификатор заказанного продукта должен быть извлечен из определенной базы данных. Ваш адрес доставки необходимо узнать из вашей учетной записи. Необходимо определить ближайший центр выполнения, на котором хранятся ваши бумажные полотенца, а затем уведомить его об удалении предмета из имеющегося запаса и упаковать его. Наконец, пакет должен быть переправлен через некоторую комбинацию самолетов, грузовиков и автобусов вместе с другими пакетами таким образом, чтобы гарантировать, что все пакеты достигнут своих целей оптимальным образом.

 

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

 

Дизайн API

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

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

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

Учет контекста — это еще одна форма согласованности, хотя она связана с внешними, по отношению к API, факторами. Отличным примером, не относящимся к программному обеспечению, является то, как правила дорожного движения или движение левой руки влияет на дизайн автомобилей для разных стран. Дизайнеры автомобилей учитывают этот фактор окружающей среды при размещении сиденья водителя по правой или левой стороне автомобиля.

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

Знание своих пользователей и учет их потребностей имеет первостепенное значение в разработке API. Пользователи вашего API будут довольны, если вы поймете, что им не нравится, и поможете избежать этого. По той же причине вы можете отказаться от иных правил дизайна API. Если вы пишете веб-API, то он, как правило, должен использовать JSON в качестве формата обмена. Однако, если ваш API будет служить научным пользователям, которые извлекают огромные объемы данных, JSON будет слишком громоздким, чтобы достойно выполнять свои функции. Зато вы можете использовать бинарный формат, например GRIB, хотя это будет очень необычный выбор.

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

Поделиться