Мне неизвестно о каких-либо конкретных исследованиях, поскольку общедоступный интерфейс к любому API очень субъективен и конкретно связан с проблемной областью.
Первые несколько страниц этого PDF-файла - хороший обзор API для делового человека:
http://aarontgrogg.com/wp-content/uploads/2009/09/How-to-Build-API-and-why-it-matters.pdf
В этом блоге публикуются ключевые моменты заголовка раздела, о которых ваши деловые партнеры должны подумать, поскольку, я думаю, вы уже в курсе. Я бы искал лучшие практики по этим конкретным предметам, поскольку они относятся к общедоступному API: http://gaejexperiments.wordpress.com/2010/07/01/public-api-design-factors/
- Формат API Rest против веб-сервисов
- Формат ответа XML, JSON
- Описание договора на обслуживание
- Механизм аутентификации для потребителей API
- Service Versioning (чтобы вы могли выкатить новые версии API, не взорвав всех)
- Ограничения скорости (очевидно, для любого количества вещей, предотвращающих атаки DOS и просто управляющих загрузкой системы)
- Документация
- Вспомогательные библиотеки
- Сайт для публики API
- В зависимости от того, какой тип API это ... КОМАНДА ПОДДЕРЖКИ
Это также не касается ваших внутренних процессов. Должны ли ваши внутренние системы развиваться быстрее, чем общедоступные API? В большинстве случаев я думаю, что ответ - да, так как ваша компания хочет быть гибкой со своей бизнес-моделью и стратегией. Если третьи лица будут использовать ваши внутренние системы, это заставит вашу компанию принять решение о том, кто важнее, когда пришло время сделать обновление. Либо вашей компании придется установить версию внутреннего сервиса и надеяться, что сторонние потребители обновятся своевременно, либо просто нарушить интеграцию для всех сторонних потребителей.
В конце концов, это может не стоить делать. Вы можете только много раз обманывать людей, использующих ваш API, прежде чем они перестанут его использовать. Что хорошего, если никто не использует его.
До этого я был в положении, когда бизнес хотел, чтобы API работал слишком быстро и без какого-либо управления. В результате все мое время было потрачено на поддержку людей, которые интегрировались с нашим API, и написание примеров кода для них.