API or not API

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

Попробуем рассмотреть известные приложения. Для начала разберем клиентское приложение, не связанное с вебом - например, электронные таблицы.
Что относится к уровню API? Ну, базовые операции над ячейками - прочитать/записать. Что еще должно быть доступно макросам, например? Выделение, операции над группами ячеек - копирование, заполнение. Создание объектов - графиков, например. Если в общем - практически все операции с данными, включая получение из внешних источников.
Что не должно относится к API? Внешний вид окна приложения - это настройки системы.
Спорные вопросы:
Сохранение и загрузка файлов - с точки зрения безопасности, лучше в API к этому доступ не давать, хотя с точки зрения проектирования возражений особых нет. Это тоже работа с данными, и скрипт обновляющий данные из сети, обновляющий графики по новым данным, может иметь возможность и сохранить результат своей работы.
Настройки расположения кнопок и панелей - на мой взгляд, это никак не должно относится к API. Контекст работы с кнопками подразумевает наличие GUI, и относится только к нему, и без GUI не имеет смысла. API для работы с данными, в свою очередь, должно работать без знания об интерфейсе - как будто его нет, или точнее, если его нет, оно должно работать так же. А значит втаскивание таких вещей в API есть грубое нарушение контекста, которое приносит головную боль как разработчикам, так и тем, кто пытается пользоваться этим функционалом. Ведь как бы разработчики не старались, все равно весь функционал GUI втащить в API не получится, значит остануться ограничения, которые будут требовать убрать - "раз сказали 'a', скажите и 'б'", и начнется напихивание в API всякого рода магии для предоставления функционала, которого не должно быть, магия будет давать сбои, пользователи будут недовольны, а корень проблемы в неверном проектном решении.

Рассмотрим теперь другой пример - веб-система, у которой есть и веб-приложение и API. Например, Google Analytics, хотя таких много.
Итак, что же есть в API: операции получения данных в самых разных разрезах - куда больше возможностей, чем в веб-приложении, надо заметить. Оно и понятно - возможности сначала появляются в API, и только потом кочуют в интерфейс, когда их обкатают и если признают популярными. Возможность просмотреть настройки - профилей, сегментов, целей.
Чего нет в API: создания / изменения сегментов и целей, почему - вопрос, видимо, все-таки не востребовано. Получения настроек интерфейса.
Вопрос: почему же нельзя из другого приложения получить пользовательские настройки в GA? 
В данном случае, это пример корректного разделения контекстов - пользовательские настройки одного веб-приложения не должны быть доступны из другого. Даже если на первый взгляд кажется, что это глупость, и пользователю от этого будет неудобно - стоит подумать еще раз и еще. Аргумент приводимый "за" - например, в приложении для мобильных устройств пользователь наверняка захочет увидеть тот же dashboard, что он настроил в основном интерфейсе. Звучит логично. К сожалению, только звучит. Во-первых, пользователь в любом случае не увидит привычного dashboard - в силу специфики мобильных устройств, и ему или будет неудобно, или он перенастроит его под мобильное представление. А если dashboard единый - то он испортит свои настройки в основном. Делать же галочки типа "разделять мобильные и основные настройки" - глупо, в настройки заходят меньше процента пользователей. Во-вторых, создатели других веб-приложений тогда радостно наступят на эти же грабли - тупо будут брать настройки dashboard из имеющегося профиля, со всеми проблемами типа синхронизации, неполной поддержки и т. п. И в результате, вместо набора хороших приложений от сторонних производителей получится куча мусора. В-третьих, если такое появляется в API, это автоматически замедляет развитие собственного интерфейса - надо ведь теперь всегда поддерживать обратную совместимость, причем не только на время обновления, а достаточно долго держать обе версии в бою. А сомнительный плюс только один - пользователь сможет увидеть свои настройки (в другом виде, вряд ли узнаваемом и удобном) в других приложениях.
Итого: из смешения контекстов вырисовывается много проблем, как для разработки, так и для пользователей. И не надо забывать, что проблемы разработки - это всегда в ближайшем будущем проблемы пользователей.


Возвращаемся к началу - где же провести границу между тем, что должно быть в API и тем, что не должно? Не претендую на последнюю версию ответа :), т.е. возможно со временем и я изменю свою точку зрения, но в настоящий момент, думаю правильные критерии таковы:
- в API должны быть все операции с данными, которые не требуют обязательного контроля человека - все операции чтения/записи данных, максимально гранулировано
- в API должен быть максимально полный функционал управления процессами в приложении - если расчеты, проводимые в приложении имеют настройки, эти настройки должны быть доступны
- в API не должно быть ничего о пользовательских настройках, не имеющих отношения к данным и процессам их обработки, т.е. все аспекты визуализации - только через интерфейс
- в API не должно быть ничего о пользователе - информация о нем, явки-пароли и т. п. - только через интерфейс, а также все его настройки уведомлений и прочее - тоже; в крайнем случае, это можно сделать через отдельное API управления пользователем, но смешивать с API данных - нельзя

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