Рекомендации по API-перехватам/обратным вызовам?

Question

Допустим, у меня есть веб-applicatons/услуги:

• API
• Набор Приложения

API используется для управления некоторыми ресурсами (простой CRUD операции). Теперь мне нужно подписаться Приложения для изменения различных API ресурсов. Приложения сделают некоторые фоновые работы по изменению.

---

Я пришел к идее обратных вызовов. Так, что Применения can oauth orise and post to API Конфигурация обратного вызова.

Я думаю, что эта конфигурация должна выглядеть следующим образом:

{ 
    'callback_url': 'http://3rdpartyservice.com/callback', 
    'resources': ['foo1', 'foo2'], 
    'ref_data':  { 'token': 'abcd1234' } 
} 

• ресурсы является массив ресурсов, третья служба сторона заинтересована в
• ref_data на заказ JSON на 3-й партии (например, для auth)

Таким образом, при указанном изменении ресурса API отправил запрос на адрес callback_url. Этот запрос будет содержать данные ресурсов, действие (создание/обновление/удаление) и ref_data.

Цель состоит в том, чтобы сделать этот родовой достаточно, чтобы позволить сторонним клиентам настраивать такие обратные вызовы.

---

Таким образом, вопрос, являются:

1. Существуют ли какие-либо рекомендации?
2. Как насчет проблем безопасности?
3. Есть ли реальные примеры в Интернете?

Tx

Answer 1

Звуки очень похожи, как WebHooks или службы Крючки.

Проверьте Web Hooks on GitHub, чтобы получить представление о том, что это такое и как они работают. См. Также последнюю alinea Service Hooks, так как объясняет, как github обрабатывает эти WebHooks. Это будет похоже на ваше приложение. OAuth объясняет, почему и как это делается.

См. Также Webhooks, REST and the Open Web, from API User Experience.

Существует даже RestHooks.

Answer 2

Общее решение этого требования обычно называется «публиковать/подписываться». Для этого существует множество решений - google "publish subscribe REST" для некоторых примеров. Вы также можете прочитать «Enterprise Integration Patterns».

Это ключевой вызов в этом виде решения «в реальном времени и в очереди».

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

В вашем примере, например, что произойдет, если вы не можете связаться с 3rdpartyservice.com? Или если http://3rdpartyservice.com/callback выдает сообщение об ошибке при публикации обновления в foo1, но не в foo2? Или если http://3rdpartyservice.com/ использует другой аромат OAuth, чем вы привыкли? Как вы гарантируете http://3rdpartyservice.com/, что это вы публикуете обновление, а не хакер?

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