Что нужно (и не нужно) моему серверному API при использовании Apigee или подобных прокси-сервисов?

Быстро вот мой сценарий: я нахожусь на ранних стадиях планирования/реализации API для моего запуска. Упомянутый API-это основа нашей стратегии и все такое. Ура!

Я собираюсь использовать Apigee (или аналогичный) для обработки всех грязных деталей(безопасность, дросселирование и т. д..) так что мне не нужно реализовывать все это самому.

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

Еще несколько технических деталей: я планирую использовать Nginx/FastCGI/Qt/C++ на моем бэк-энде, возможно, не относящемся к делу. Звонки на этот сервер будут осуществляться исключительно через прокси (Apigee). У меня будет собственный клиентский веб-сайт и внутренние приложения, использующие API в качестве корма для собак.

То, что я ищу, - это руководство по лучшей практике реализации моей стороны API при использовании чего-то вроде Apigee в качестве фундаментального компонента общей стратегии. Я не хочу изобретать никаких колес (или стреляю себе в ногу)!

Является ли это вообще правильным подходом ?

Спасибо вам всем !!

4 2
api backend

4 ответа:

Колин,

То, что вы ищете, - это лучшие практики API Façade. [С или без Apigee.]

Вот некоторые лучшие практики типа контента, который генерируется людьми Apigee-однако более важно - они не основаны непосредственно на использовании технологии Apigee как таковой. Эти рекомендации применимы к любому основанному на REST API фасадному слою.

Надеюсь, это поможет.

  1. электронная книга по шаблонам фасадов API
  2. видео-плейлист шаблона фасада API Вебинеры
1

Где поместить функциональность в поток обычно контекстуально, но есть несколько простых вещей, которые можно поместить в каждый прокси:

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

2) Основные Политики Безопасности: Как только вы узнаете, что приложение имеет доступ к вашему API, есть несколько простых политик безопасности, которые должны выполняться на уровне Apigee. Принудительное использование полезных данных (защита от угроз JSON и XML, регулярные выражения для блокирования таких вещей, как SQL-инъекция или другой инвазивный код). Вы также можете установить квоты на основе ключа API (разные разработчики получают разные уровни доступа на основе продуктов, которые вы связываете с их ключами). Вы также хотите установить Спайк-аресты, чтобы сохранить трафик API от подавление вашего целевого сервера.

3) Управление ответами: убедитесь, что вы убрали ненужные заголовки ответов (файлы cookie, версии сервера и т. д.), которые не относятся к контракту API. Нет необходимости рассказывать разработчикам приложений о вашей целевой архитектуре, но иногда бывает трудно подавить эти заголовки с серверов приложений. Также может потребоваться, чтобы правила блокировали неожиданные ответы от целевого сервера (например, 500 ошибок, которые могут содержать трассировки стека).

4) кэширование: Возможность кэшировать ответы в Apigee приводит к большому количеству остальных вопросов "где это сделать". Но возможность возвращать кэшированный ответ от Apigee может уменьшить вашу задержку на сотни миллисекунд, улучшая ваши транзакции в секунду и удовлетворяя вашего разработчика / потребителя. Теперь возникает вопрос, насколько точно вы можете получить кэшированный ответ, не обращаясь к целевому серверу.

Кроме того, он становится "где легче и эффективнее всего выполнить задачу?" Такие вещи, как JSON в XML, например, просты в Apigee, но они просты и в других платформах, которые могут работать на вашем бэкэнд-сервере.

9

Хороший вопрос-раскрытие я работаю для 3scale (http://www.3scale.net ) и мы конкурируем с Апигеем. Но я постараюсь ответить на этот вопрос нейтрально.

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

  • убедитесь, что набор внутренних конечных точек, которые вы имеете, масштабируется с проходящим через него трафиком.
  • различные шлюзы могут устанавливать заголовки элементов управления, которые вы хотите найти в своем коде (например, идентификаторы пользователей, хэши, маркеры безопасности).
  • вы, вероятно, захотите настроить серверную часть для приема трафика из ниоткуда через шлюзы.

Сказав Все это - я бы рекомендовал вам проверить 3scale - мы предоставляем эквивалентные услуги Apigee, включая шлюз API. Это не только более экономично (см. сайт), но наше решение также основано на NGINX, который уже есть в вашем стеке - вы можете добавить другой или добавить в существующий конфиг.

Надеюсь, что это поможет и рад дать больше информации, если это полезно.

2

Стек Apigee 4G удивителен! Я очень впечатлен их реализацией на многих уровнях (кстати: "клиент", а не "конкурент"), и, честно говоря, я уже давно не смотрел на 3Scale, поэтому я отстал от времени с их продуктом

Функциональность Apigee удивительно богата, ослепительно быстра и легка с очень малой задержкой от процесса.

Помимо услуг шлюза, аналитические возможности для использования, предоставляемые Apigee, также являются основной продажей точка; Я удивлен тем, как в темноте я был, пока не начал использовать аналитические данные.

Смотрите видео здесь: https://community.apigee.com/learn/create-and-manage-apis

Есть и аналитический ряд.

2