Компания, в которой я работаю, поддерживает успешный продукт SaaS, который «органично» рос за эти годы. Мы планируем расширить линейку новыми продуктами, которые будут обмениваться данными с существующим продуктом. Чтобы поддержать это, мы стремимся объединить бизнес-логику в одном месте: уровень веб-службы. Слой WS будет использоваться:
- Веб-приложения
- Инструмент для импорта данных
- Инструмент для интеграции с другим клиентским программным обеспечением (не API по сути)
Мы также хотим создать API, который может использоваться нашими клиентами, которые могут использовать его для создания своих собственных интеграций. Мы боремся со следующим вопросом:
Должны ли внутренний API (он же уровень WS) и внешний API быть одним и тем же, с настройками безопасности и разрешений для управления тем, что может делать кто, или они должны быть двумя отдельными приложениями, где внешний API просто вызывает внутренний API как и любое другое приложение? Пока что в наших дебатах кажется, что их разделение может быть более безопасным, но добавит накладных расходов.
Что другие сделали в подобной ситуации?
источник
Ответы:
Всегда полезно есть свою собачью еду. Один API также должен быть проще в обслуживании, чем два, даже если вы учитываете некоторые накладные расходы для аутентификации и авторизации.
источник
Хотя я согласен с Aneurysm9, иногда вы не хотите раскрывать все возможности вашей системы. В этом случае было бы предпочтительнее иметь два API ... НО, если вы выбрали такой способ ... убедитесь, что все общие функции используют один и тот же API, т. Е. Один является расширенной версией другого, в отличие от двух разных наборы кода.
Таким образом, вы можете использовать свое собственное для себя, имея место для частной, чувствительной, экспериментальной работы, в то же время позволяя вам публиковать и использовать новые материалы, не слишком меняя общедоступный API.
источник
Я сталкивался с этим раньше (много раз), и в итоге я предпочел:
Возьмите BL с сайта. Сделайте сайт потребителем API. Относитесь к сайту как к другому клиенту вашего API. Ваш API - это сервис.
Если вы думаете, что вам нужны специальные методы API только для сайта, подумайте еще раз! Если это хорошо для гуся, это хорошо для гусенка. Если вам действительно очень нужны специальные функциональные возможности для веб-сайта, я бы сказал, что вы действительно обнаружили разницу в «профиле пользователя», и, следовательно, это ситуация, когда API все еще должен поддерживать «специальные» функции, но тогда вы контролировать их через авторизацию.
Не убежден?
Сделайте парадигму на шаг дальше ...
Приложение телефона работает на платформе, где выполняется байт-код, приложение живет в телефоне и использует API-сервисы через HTTP / JSON.
Веб-сайт - это приложение, работающее на платформе, где исполняется HTML + Javascript, приложение живет в браузере и использует службы API через HTTP / JSON.
То же самое!
Распространите это на планшеты, телевизоры, другие телефонные платформы, плагины, сторонние приложения, гибридные приложения, ...
Множество различных пользовательских интерфейсов, подключенных к общему API.
Ваше приложение - это API. Сайт - только один клиент (из многих)
источник
Используйте один API
Если вы реализуете API службы в качестве уровня REST, просто добавьте аутентификацию к защищенным маршрутам.
Вы, вероятно, захотите использовать среду разработки, которая не требует много магии. Что-то, где вы можете определить маршруты напрямую без большого количества обратного проектирования.
Подумайте, например, Node.js / Express, python / pylons, python / google app engine и т. Д.
Недавно я реализовал это в Google App Engine для API REST / Datastore, и я не думаю, что это могло бы быть проще. Контроллеры реализованы как классы, а их последующие HTTP-запросы (т.е. GET / POST / PUT / DELETE) реализованы как методы этих классов. Мне удалось реализовать basic-auth как декоратор. Это сделало добавление требования аутентификации к запросу таким же простым, как подключение декоратора @basicAuth.
Таким образом, я мог бы сделать входящие запросы GET общедоступными, добавив требование аутентификации к запросам POST / PUT / DELETE на том же контроллере для этой модели.
Если вы знаете, как говорить в REST, жизнь становится намного проще, потому что поддержка REST уже встроена в любой веб-сервер (т. Е. HTTP - это просто тип REST API). Вы даже можете выбрать прозрачное сжатие GZIP, если вы отправляете много данных по сети.
источник
Мое первое впечатление состоит в том, что это должен быть тот же API, и что ваша безопасность должна быть на другом уровне. Возможно, с веб-фронтом?
источник