Мне было интересно, может ли кто-нибудь дать совет относительно плюсов и минусов между использованием Mashery и Apigee для документирования API? У меня есть некоторые оценки, и у меня есть около 2 недель, чтобы придумать предложение относительно того, что использовать. Я использовал Mashery, но недостаточно Apigee, чтобы понять, в чем разница.
Любые ресурсы, на которые вы могли бы мне указать, или анекдотический совет, который вы могли бы мне дать, были бы очень признательны.
Я также опубликовал этот вопрос в группе API Writers, но я публикую перекрестные сообщения, потому что у этой группы более широкая аудитория.
Заранее спасибо.
Сравнивать напрямую сложно, потому что не так часто можно найти кого-то, кто имеет опыт использования как Mashery, так и Apigee. Итак, со стороны Mashery я могу прокомментировать то, что доступно, потому что я хорошо знаком с решением.
Для документирования API у Mashery есть две функции продукта, которые являются стандартными для всех клиентов: (1) подробная документация CMS (система управления контентом) с контролем доступа на основе ролей и (2) интерактивная документация (I/O Docs) с полной интеграцией авторизации. .
CMS для длинных документов проста. Он предоставляет простой способ создания иерархических документов с помощью простого HTML-редактора WYSIWYG или прямого HTML. У вас также есть полный контроль над стилем с помощью шаблонов CSS или даже встроенного внедряемого CSS, а также возможность загружать удаленный JS или также выполнять встроенный вводимый JS.
Примеры длинной формы:
Tribune Media Services: http://developer.tmsapi.com/docs/read/data_v1/lineups/Lineups_by_zipcode
Expedia Affiliate Network: http://developer.ean.com/docs/read/hotel_list
Для интерактивных документов Mashery предлагает I/O Docs. I/O Docs настроен со схемой JSON и интегрирован в портал разработчика, поэтому, когда разработчик входит в систему, автоматически заполняются схемы авторизации и ключи API. I/O Docs является гибким и, к лучшему или к худшему, отделен от любого другого определения API, что позволяет техническому писателю настроить I/O Docs так, чтобы он вел себя не только как справочный документ и инструмент тестирования, но и как средство обучения ( т.е. пошаговая настройка с подробным описанием ресурсов, методов и параметров).
Примеры документов ввода-вывода:
FoodEssentials: http://developer.foodessentials.com/io-docs (step-by-step style)
Tribune Media Services: http://developer.tmsapi.com/io-docs
EPSN: http://developer.espn.com/io-docs
С Mashery управление трафиком и порталом осуществляется в одном месте. Все это очень тесно связано между собой. Конечно, это одно из самых больших отличий — управление. Опять же, хорошо это или плохо, но Apigee использует Drupal в качестве CMS, и он работает как отдельная единица, которой нужно управлять. В отличие от этого стек портала для разработчиков Mashery является многопользовательским SaaS и полностью управляемым.
На ум пришел один человек/компания, Питер из SDK Bridge. Я полагаю, что его компания написала/внедрила документацию для одного или нескольких клиентов Mashery, а также для платформ, не входящих в семейство Mashery. Вполне возможно, что он уже здесь, но если нет, может быть, проверьте, предоставит ли он сравнение: http://sdkbridge.com/documentation.php - он не связан и не работает с Mashery.
Отказ от ответственности: я евангелист платформ с Mashery (евангелист API наших клиентов) — поэтому я хорошо знаю нескольких технических писателей и архитекторов API. :)
Удачи!
Моника Челлио