Meilleures pratiques pour les hooks/rappels d'API?

Question

Disons que j'ai web applicatons/services:

• API
• Ensemble de Applications

API est utilisé pour la gestion des ressources (opérations CRUD simples). Maintenant ce que j'ai besoin est de vous abonner Applications pour les changements de différentes ressources API. Les applications feraient du travail de fond sur un changement.

---

Je suis venu à l'idée des rappels. Alors que Applications peut oauth orise et poster à l'API une config de rappel.

Je pense que cette configuration devrait ressembler à ceci:

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

• ressources est un tableau des ressources que le service 3ème partie est intéressé par
• ref_data est JSON sur mesure pour la 3ème partie utilisation (par exemple pour auth)

De cette façon, sur une ressource spécifiée, changez le API enverra une demande à callback_url. Cette requête contiendrait des données de ressource, une action (créer/mettre à jour/supprimer) et ref_data.

L'intention ici est de rendre cela assez générique pour permettre aux clients tiers de configurer de tels rappels.

---

La question sont:

1. Y a-t-il des meilleures pratiques?
2. Qu'en est-il des problèmes potentiels de sécurité?
3. Existe-t-il des exemples concrets sur le Web?

Tx

Answer 1

Cela semble très similaire à crochets service WebHooks ou .

Consultez le Web Hooks on GitHub, pour avoir une bonne idée de ce qu'ils sont et comment ils fonctionnent. Voir aussi le dernier alinea Service Hooks, car il explique comment github gère ces WebHooks. Ce serait similaire pour votre application. Le OAuth explique pourquoi et comment cela est fait.

Voir également Webhooks, REST and the Open Web, à partir de API User Experience.

Il y a même RestHooks.

Answer 2

La solution générale à cette exigence est généralement appelée "publication/abonnement". Il existe des dizaines de solutions à cela - google "publier souscrire REST" pour quelques exemples. Vous pouvez également lire "Enterprise Integration Patterns".

Le principal défi de ce type de solution est "temps réel par rapport à la file d'attente". Par exemple, si vous avez une API avec un million de clients, qui sont tous intéressés par le même événement, vous ne pouvez pas garantir qu'en temps réel, vous pouvez atteindre tous ces clients dans les délais requis par leur application. Vous devez également vous inquiéter du départ du réseau ou de l'arrêt temporaire des clients. Dans ce cas, votre application peut définir une file d'attente d'événements, et les clients recherchent dans cette file les événements qui les intéressent. Une fois que vous avez emprunté cette route, vous allez probablement utiliser un logiciel standard plutôt que de construire le tien. Apache Camel est une bonne implémentation open source.

Dans votre exemple, par exemple, que se passe-t-il si vous ne pouvez pas atteindre 3rdpartyservice.com? Ou si http://3rdpartyservice.com/callback renvoie une erreur lors de l'envoi d'une mise à jour à foo1, mais pas à foo2? Ou si http://3rdpartyservice.com/ utilise une saveur différente de OAuth que vous êtes habitué? Comment garantissez-vous http://3rdpartyservice.com/ que c'est vous qui publiez une mise à jour, pas un hacker? Vos choix ont vraiment tendance à se résumer à vos besoins non fonctionnels, plutôt que ceux fonctionnels - des choses comme le temps de fonctionnement, la garantie de notification, la garantie de livraison, etc. sont plus importants que les spécificités de la façon dont vous traversez la paramètres, et si c'est «basé sur les ressources» ou un autre protocole.