Внутренняя и внешняя архитектура API

19

Компания, в которой я работаю, поддерживает успешный продукт SaaS, который «органично» рос за эти годы. Мы планируем расширить линейку новыми продуктами, которые будут обмениваться данными с существующим продуктом. Чтобы поддержать это, мы стремимся объединить бизнес-логику в одном месте: уровень веб-службы. Слой WS будет использоваться:

  • Веб-приложения
  • Инструмент для импорта данных
  • Инструмент для интеграции с другим клиентским программным обеспечением (не API по сути)

Мы также хотим создать API, который может использоваться нашими клиентами, которые могут использовать его для создания своих собственных интеграций. Мы боремся со следующим вопросом:

Должны ли внутренний API (он же уровень WS) и внешний API быть одним и тем же, с настройками безопасности и разрешений для управления тем, что может делать кто, или они должны быть двумя отдельными приложениями, где внешний API просто вызывает внутренний API как и любое другое приложение? Пока что в наших дебатах кажется, что их разделение может быть более безопасным, но добавит накладных расходов.

Что другие сделали в подобной ситуации?

Дрю Гудвин
источник
Если вы купите хороший фреймворк для SOA, все эти дебаты будут спорными. Планируете ли вы внедрять свою собственную платформу SOA? Почему? Если это успешный продукт, почему бы не лицензировать JCAPS от Oracle? Или WebSphere от IBM? Тогда безопасность уровня WS становится повсеместной и прозрачной.
S.Lott
1
@ S.Lott На самом деле не так сложно написать слой SOA. Ни одна из этих платформ не основана на REST; это 2012 не так ли? Это звучит ужасно "предприимчиво".
Эван Плейс
Почему бы не иметь сервисный слой поверх вашей доменной модели, тогда вы можете использовать те же сервисы внутри вашего исходного кода.
M.abuelezz

Ответы:

13

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

Aneurysm9
источник
4
Мне нравится, как вы это выразили. Наличие двух отдельных слоев в конечном итоге будет означать изменение вещей в двух местах много раз в будущем, дополнительное тестирование и много общего безумия, пытаясь выяснить, почему вещи вышли из синхронизации. Если бы у меня было достаточно репутации, чтобы проголосовать за ваш ответ, я бы сделал это :)
Дрю Гудвин
5

Хотя я согласен с Aneurysm9, иногда вы не хотите раскрывать все возможности вашей системы. В этом случае было бы предпочтительнее иметь два API ... НО, если вы выбрали такой способ ... убедитесь, что все общие функции используют один и тот же API, т. Е. Один является расширенной версией другого, в отличие от двух разных наборы кода.

Таким образом, вы можете использовать свое собственное для себя, имея место для частной, чувствительной, экспериментальной работы, в то же время позволяя вам публиковать и использовать новые материалы, не слишком меняя общедоступный API.

Newtopian
источник
3
Я думаю, что мы здесь согласны. Используйте уровень безопасности, чтобы ограничить расширенный набор функций для внутренних пользователей. Таким образом, у вас есть один API, но несколько уровней разрешений для доступа к API.
Аневризма9
Я думаю о том, чтобы сделать это самому и справиться с этим, сделав свое приложение пользователем с повышенными привилегиями. Сложно обернуть мой мозг. Я думаю, что мне нужно применить Hammock Driven Development на этом.
AJB
4

Я сталкивался с этим раньше (много раз), и в итоге я предпочел:

Возьмите BL с сайта. Сделайте сайт потребителем API. Относитесь к сайту как к другому клиенту вашего API. Ваш API - это сервис.

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

Не убежден?

Сделайте парадигму на шаг дальше ...

Приложение телефона работает на платформе, где выполняется байт-код, приложение живет в телефоне и использует API-сервисы через HTTP / JSON.

Веб-сайт - это приложение, работающее на платформе, где исполняется HTML + Javascript, приложение живет в браузере и использует службы API через HTTP / JSON.

То же самое!

Распространите это на планшеты, телевизоры, другие телефонные платформы, плагины, сторонние приложения, гибридные приложения, ...

Множество различных пользовательских интерфейсов, подключенных к общему API.

Ваше приложение - это API. Сайт - только один клиент (из многих)

Джейсон Гловер
источник
Понимание того, что API - это весь прикладной уровень, а различные версии (ОС, браузер, планшет, телефон) - просто клиенты API, привело меня к A-Ha! момент только сейчас.
AJB
2

Используйте один 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, если вы отправляете много данных по сети.

Эван Плейс
источник
-1

Мое первое впечатление состоит в том, что это должен быть тот же API, и что ваша безопасность должна быть на другом уровне. Возможно, с веб-фронтом?

vegai
источник
2
иногда проблемы безопасности копают намного глубже, чем простое шифрование и подпись транзакций. Таким образом, вполне возможно, что некоторые или даже многие элементы, ориентированные на безопасность, всплывают в вашем основном API. Тем не менее, я бы согласился с вами в попытке сохранить его как можно более отдельным.
Newtopian