Код, управляющий данными – бизнес-логика реализации, – может влиять на проектирование API. Открытие доступа к такой логике через API может докучать не только потребителю, но и поставщику. На рис. 2.19 показан такой пример.

Допустим, что для реализации нашего API онлайн-магазина у каждого клиента есть один активный адрес. Но адреса в системе никогда не удаляются; вместо этого их статус становится неактивным, когда клиент не пользуется услугами сайта. Проектирование API, на который влияет эта бизнес-логика, может обеспечить следующие ориентированные на поставщика цели:
— составляем список адресов клиентов (активных и неактивных);
— добавляем адрес клиента;
— обновляем статус адреса (на активный или неактивный).
Слова, используемые для описания этих целей, понятны, но общее назначение целей может быть неочевидно для потребителя, который не знает точно, как система обрабатывает адреса. Эти цели показывают, как данные обрабатываются внутри; на рис. 2.20 показано, как их нужно использовать.

В левой части рисунка показано, как изменить адрес клиента с помощью этого API. Потребители должны перечислить существующие адреса, чтобы определить активный, обновить их, чтобы установить статус «неактивный», а затем добавить новый активный адрес. Довольно просто, нет? Вовсе нет! Это очень сложный процесс, и здесь легко что-нибудь может пойти не так. Что, если потребители не установят для предыдущего адреса значение «неактивный»? Это может стать катастрофой для целостности данных – здесь рискует поставщик.

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

ПОДСКАЗКА. При определении целей API всегда следует проверять, чтобы вы случайно не предоставили доступ к внутренней бизнес-логике, которая не касается потребителя и которая может быть опасной для поставщика.

Здесь мы имели дело только с одним программным компонентом.