Sagen wir, ich habe Webapplikationen / Dienste:
API wird zur Verwaltung einiger Ressourcen verwendet (einfache CRUD-Operationen). Jetzt muss ich Anwendungen für Änderungen von verschiedenen API Ressourcen abonnieren. Anwendungen würden einige Hintergrundarbeiten an einer Änderung vornehmen.
Ich kam auf die Idee von Rückrufen. Damit Anwendungen kann oauth eine Callback-Konfiguration oristieren und an die API senden.
Ich denke, dass diese Konfiguration wie folgt aussehen sollte:
%Vor%Auf diese Weise würde bei der angegebenen Ressourcenänderung die API eine Anforderung an callback_url senden. Diese Anfrage würde Ressourcendaten, action (create / update / delete) und ref_data enthalten.
Die Absicht ist, dies generisch genug zu machen, damit Drittanbieter-Clients solche Rückrufe konfigurieren können.
Die Frage ist also:
Tx
Klingt sehr ähnlich wie WebHooks oder Service-Hooks .
Sieh dir die Web-Hooks auf GitHub an, um eine gute Vorstellung davon zu bekommen, was sie sind und wie sie funktionieren. Siehe auch die letzten Service-Hooks , in denen erklärt wird, wie github diese WebHooks behandelt. Dies wäre für Ihre Anwendung ähnlich. Das OAuth erklärt warum und wie es gemacht wird.
Siehe auch Webhooks, REST und das offene Web von API User Experience .
Es gibt sogar RestHooks .
Die allgemeine Lösung für diese Anforderung wird normalerweise "publish / subscribe" genannt. Es gibt Dutzende von Lösungen dazu - google "publish subscribe REST" für einige Beispiele. Sie können auch " Enterprise Integration Patterns " lesen.
Die Schlüsselherausforderung bei dieser Art von Lösung ist "Echtzeit versus Warteschlange".
Wenn Sie zum Beispiel eine API mit einer Million Clients haben, die alle an demselben Ereignis interessiert sind, können Sie nicht garantieren, dass Sie in Echtzeit alle diese Clients innerhalb des von der Anwendung geforderten Zeitrahmens erreichen können. Sie müssen sich auch Sorgen machen, dass das Netzwerk ausfällt oder dass Clients vorübergehend nicht verfügbar sind. In diesem Fall definiert Ihre Anwendung möglicherweise eine Ereigniswarteschlange und die Clients suchen in dieser Warteschlange nach Ereignissen, an denen sie interessiert sind. Wenn Sie diese Route gewählt haben, verwenden Sie wahrscheinlich eher Software von der Stange als das Erstellen dein eigenes. Apache Camel ist eine gute Open-Source-Implementierung.
In Ihrem Beispiel zum Beispiel, was passiert, wenn Sie 3rdpartyservice.com nicht erreichen können? Oder wenn Ссылка beim Posten eines Updates auf foo1 einen Fehler ausgibt, aber nicht auf foo2? Oder wenn Ссылка eine andere Art von OAuth verwendet als Sie gewohnt sind? Wie garantieren Sie Ссылка , dass Sie es sind, der ein Update veröffentlicht, kein Hacker?
Ihre Entscheidungen neigen eher dazu, sich auf Ihre nicht-funktionalen Anforderungen als auf die funktionalen Anforderungen zu beziehen - Dinge wie Betriebszeit, Garantie der Benachrichtigung, Liefergarantie usw. sind wichtiger als die Besonderheiten, wie Sie die Parameter übergeben und ob es "ressourcenbasiert" oder ein anderes Protokoll ist.
Tags und Links api web-services callback soa webhooks