APIs vs. Webhooks: Was ist der Unterschied?

APIs und Webhooks ermöglichen es verschiedenen Softwaresystemen, Informationen zu synchronisieren und auszutauschen. Da Softwareanwendungen zunehmend miteinander verbunden sind, ist es für Entwickler unerlässlich, den Unterschied zwischen diesen beiden Arten des Datenaustauschs zu verstehen und das Tool auszuwählen, das den Anforderungen der jeweiligen Aufgabe am besten entspricht.

Was ist eine API?

Eine API ist wie ein Portal, über das Informationen und Funktionen zwischen zwei Softwarediensten ausgetauscht werden können. Das Wort „Schnittstelle“ ist der Schlüssel zum Verständnis des Zwecks einer API. So wie ein Webbrowser eine Schnittstelle für einen menschlichen Endbenutzer ist, um Informationen auf einem Webserver zu empfangen, zu senden und zu aktualisieren, ist eine API eine Schnittstelle, die Softwareprogrammen dieselbe Funktionalität bietet.

Es gibt verschiedene Arten und Kategorien von APIs (die wir später untersuchen werden), aber allgemein definiert sind APIs die gebräuchlichste Methode für verschiedene Softwaresysteme, Informationen zu verbinden und auszutauschen. Derzeit Programmierbares Web bietet eine Datenbank mit über 23.000 APIs, die sich mit allem befassen, von globalen epidemiologischen Daten bis hin zu Papa-Witzen. Jede API ist eine leere Leinwand, die darauf wartet, dass Entwickler sie in andere Anwendungen integrieren und auf neue, kreative Weise verwenden.

Was ist ein Webhook?

Ein Webhook kann als eine Art API betrachtet werden, die eher von Ereignissen als von Anfragen gesteuert wird. Anstatt dass eine Anwendung eine Anfrage an eine andere stellt, um eine Antwort zu erhalten, ist ein Webhook ein Dienst, der es einem Programm ermöglicht, Daten an ein anderes zu senden, sobald ein bestimmtes Ereignis eintritt. Webhooks werden manchmal als „Reverse-APIs“ bezeichnet, da die Kommunikation von der Anwendung initiiert wird, die die Daten sendet, und nicht von der, die sie empfängt. Da Webdienste zunehmend miteinander vernetzt werden, werden Webhooks immer beliebter. Sie sind eine einfache Lösung, um Benachrichtigungen und Datenaktualisierungen in Echtzeit zu ermöglichen, ohne dass eine vollständige API entwickelt werden muss.

Angenommen, du möchtest Slack-Benachrichtigungen erhalten, wenn Tweets veröffentlicht werden, die einen bestimmten Account erwähnen und einen bestimmten Hashtag enthalten. Anstatt dass Slack Twitter ständig nach neuen Posts fragt, die diese Kriterien erfüllen, ist es für Twitter viel sinnvoller, nur dann eine Benachrichtigung an Slack zu senden, wenn dieses Ereignis stattfindet. Dies ist der Zweck eines Webhooks — anstatt die Daten wiederholt anfordern zu müssen, kann sich die empfangende Anwendung zurücklehnen und das abrufen, was sie benötigt, ohne wiederholte Anfragen an ein anderes System senden zu müssen.

APIs ermöglichen robuste Integrationen

Ein wichtiges Merkmal von APIs besteht darin, dass sie eine bidirektionale Kommunikation zwischen verschiedenen Softwareprogrammen über einen Anfrage-Antwort-Zyklus ermöglichen, wobei am häufigsten die HTTP-Protokoll. In einem typischen API-Anwendungsfall fragt ein Softwareprogramm mithilfe einer HTTP-GET-Anfrage von einem anderen nach einem bestimmten Datensatz. Sofern die Anfrage gültig ist, antwortet das empfangende System mit den angeforderten Daten in einem maschinenlesbaren Format, üblicherweise XML oder JSON. Auf diese Weise können Anwendungen Daten unabhängig von ihren individuellen Programmiersprachen oder internen Spezifikationen austauschen. Der universelle Charakter von API-Interaktionen kann unzählige Szenarien ermöglichen, von einem iPhone-Benutzer, der die lokale Temperatur überprüft, über die AccuWeather-API an einen Uber-Fahrer, der über die Google Maps-API zu seinem nächsten Abholort navigiert.

APIs empfangen nicht nur Daten, sondern können auch die gesamte Bandbreite der „CRUD“ -Operationen (Create, Read, Update and Delete) zwischen zwei Anwendungen verarbeiten. Mit anderen Worten, APIs dienen nicht nur dazu, einem Benutzer Daten in einer Oberfläche anzuzeigen — sie können auch verwendet werden, um Änderungen an ihnen in der Anwendung vorzunehmen, in der sie gespeichert sind. Auf diese Weise ermöglichen APIs Softwaresystemen, ihre Dienste und Funktionen zu erweitern und sich gründlicher und sinnvoller in andere Plattformen zu integrieren.

Die Vielseitigkeit von APIs macht sie zu leistungsstarken Tools für Entwickler, um die Funktionen ihrer Anwendungen zu erweitern. Die meisten modernen Webdienste enthalten APIs, mit denen ihre Daten und Funktionen in andere Tools integriert werden können. Tatsächlich ist es selten, dass ein Unternehmens-Webservice eine API von mindestens einer anderen Anwendung in gewissem Maße nutzt.

Webhooks bieten einfachen Datenaustausch

Man könnte meinen, dass Webhooks, da es sich um Echtzeitereignisse handelt, technisch schwierig zu implementieren sind. Tatsächlich besteht ein wesentlicher Vorteil von Webhooks darin, dass sie einfacher einzurichten sind und weniger ressourcenintensiv sind als APIs. Das Erstellen einer API ist ein komplexer Prozess, der in einigen Fällen genauso schwierig sein kann wie das Entwerfen und Erstellen einer Anwendung selbst. Die Implementierung eines Webhooks erfordert jedoch lediglich das Einrichten einer einzelnen POST-Anfrage auf der sendenden Seite, die Einrichtung einer URL auf der Empfangsseite, um die Daten zu akzeptieren, und dann, sobald sie empfangen wurden, einige Aktionen an den Daten durchzuführen.

Zu den häufigsten Anwendungsfällen für Webhooks gehören das Senden neuer An- und Abmeldungen von E-Mail-Listen an ein CRM-System, die automatische Aktualisierung der Buchhaltungssoftware, wenn Rechnungen bezahlt werden, oder das Einrichten jeglicher Art von Benachrichtigungen. Bei jeder dieser Arten von Ereignissen fließen die Informationen in eine Richtung, und es ist keine Anfrage erforderlich, um aktualisierte Daten zu erhalten.

Dieselben Eigenschaften, die die Implementierung von Webhooks relativ einfach machen, sind auch der Grund, warum sie weitaus eingeschränkter sind als APIs. Das Aktualisieren der Daten, die ein Webhook liefert, erfordert eine vollständige Neukonfiguration, um auf ein anderes Ereignis zu warten. In den meisten Fällen wäre es effizienter, einen neuen Webhook zu erstellen. Wenn zwei Systeme Daten über eine API mit mehreren Endpunkten teilen, hat das Empfangssystem Zugriff auf ein viel breiteres Datenspektrum aus dem sendenden System. Im Gegensatz zu APIs ermöglichen Webhooks dem sendenden System außerdem nicht, Daten auf der Empfangsseite hinzuzufügen, zu aktualisieren und zu löschen, weshalb Webhooks allein zu begrenzt sind, um eine vollständige Integration zwischen zwei Anwendungen zu bieten.

API-Architektur: Gegenwart und Zukunft

APIs fallen je nach den Protokollen und Architekturen, die definieren, wie sie Daten senden und empfangen, in verschiedene Kategorien. In der Vergangenheit war REST das gängigste Architekturmuster für das API-Design, insbesondere für diejenigen, die webbasierte Anwendungen betreuen.

REST steht für „Representational State Transfer“. Dieses Muster, definiert durch Roy Fielding im Jahr 2000 ermöglicht es zwei Anwendungen, über HTTP auf ähnliche Weise wie Browser und Server zu kommunizieren. REST ist kein offizieller Standard, sondern eine Reihe von Vorschlägen zum Design von APIs und anderen Webdiensten. Eine API gilt als „RESTful“, wenn ihr Design den folgenden Empfehlungen entspricht:

• Client-Server: Genau wie ein Browser, der eine Webseite von einem Server anfordert, sendet Anwendung A in einer RESTful-API über HTTP eine Anfrage an eine URL, die auf Anwendung B gehostet wird. Anwendung B wertet dann die Anfrage aus und gibt entweder die angeforderten Daten oder eine Fehlermeldung zurück.
• Staatenlos: Das antwortende System muss nichts über den Anwendungsstatus des Systems wissen, das die Anfrage stellt, um eine angemessene Antwort zu geben. Die Anfrage allein sollte alle Informationen enthalten, die für die Beantwortung erforderlich sind.
• Cachefähigkeit: Die Antwort sollte angeben, ob das empfangende System es zwischenspeichern darf oder nicht.
• Mehrschichtige Systeme: Die API ist nicht auf ein bestimmtes System angewiesen, um die Anfrage zu stellen, um die Antwort zu liefern. Das bedeutet, dass das anfordernde System entweder ein Client, ein Proxy oder ein anderer Vermittler sein kann.

So einfach Beispiel folgt den REST-Konventionen. Wenn Sie die URL aufrufen, zeigt Ihr Browser eine vorgeschlagene Aktivität an, an der Sie teilnehmen können, wenn Sie sich im JSON-Format langweilen:

{
  "activity": "Go to a concert with some friends",
  "type": "social",
  "participants": 4,
  "price": 0.6,
  "link": "",
  "key": "4558850",
  "accessibility": 0.4
}

Egal, wie Sie eine Anfrage an diese URL stellen — ob mit Ihrem Browser, mit LOCKEN, oder eine HTTP-Client-Bibliothek wie abrufen in JavaScript — Die API gibt dasselbe Objekt zurück. Neben REST gehören zu den weiteren API-Konventionen SEIFE, KOBRA und XML-RPC. Bis heute ist REST jedoch der am weitesten verbreitete Satz von API-Architekturrichtlinien.

Im Jahr 2015 veröffentlichte das Engineering-Team von Facebook GraphQL— eine neue Abfragesprache für APIs, die eine flexiblere Alternative zum Senden von Anfragen an Endpunkte auf REST-APIs bieten soll. Ohne zu tief in die Komplexität von GraphQL einzutauchen, besteht der Hauptvorteil gegenüber herkömmlichen REST-APIs in der Fähigkeit, bei jeder Anfrage genau die benötigten Daten zurückzugeben und gleichzeitig „Überabrufe“ und „Unterabrufe“ zu vermeiden, Probleme, die normalerweise bei herkömmlichen APIs auftreten.

Stellen Sie sich beispielsweise die folgende Situation vor. Eine Restaurantbewertungs-App muss die Titel der neuesten Bewertungen anzeigen, die ein Benutzer veröffentlicht hat, zusammen mit den letzten drei Personen, die diesem Benutzer gefolgt sind. Bei Verwendung einer REST-API müsste der Kunde in der Regel drei verschiedene Anfragen an verschiedene Endpunkte stellen — eine, um die ursprünglichen Benutzerdaten abzurufen, eine zweite, um alle Bewertungen für diesen Benutzer zurückzugeben, und eine dritte, um eine Liste der Follower dieses Benutzers zurückzugeben. Mit GraphQL könnte ein Client mit einer einzigen Abfrage auf dieselben Daten zugreifen, die den genauen Anforderungen entsprechen:

query {
    User(id: "qr3fsdcv24") {
        name
        posts {
            title
        }
        followers(last: 3) {
            name
        }
    }
}

APIs bei der Arbeit in mParticle

APIs sind das Arbeitspferd des technischen Ökosystems von mParticle. Sie sind ein großer Teil dessen, was es mParticle ermöglicht, eine Omnichannel-Ansicht Ihrer Kunden zu erstellen und diese Profile mit Tools in Ihrem gesamten Marketing-Stack zu teilen. Die über 280 direkten Integrationen von mParticle mit führenden Marketing-, Analyse- und Data-Warehousing-Lösungen basieren alle auf umfangreichen benutzerdefinierten APIs, die die Komplexität des Sendens von Echtzeitdaten und vereinheitlichten Benutzerprofilen an nachgelagerte Systeme vereinfachen.

Anstatt einfacher Webhook-Integrationen, die auf unidirektionale Datenfeeds beschränkt sind, basieren die Partnerintegrationen von mParticle auf vollständigen APIs, die eine viel robustere Interaktion zwischen den beiden Systemen ermöglichen. Diese APIs sind hinter den Kulissen immer sehr aktiv, zum Beispiel wenn mParticle-Kunden den Fluss ihrer Daten in der mParticle-Benutzeroberfläche nahtlos steuern.

Die Profil-API: Fragen Sie Ihre mParticle-Benutzerprofile direkt ab

Zusätzlich zu den APIs, die Partnerintegrationen unterstützen, bietet mParticle Entwicklern von Partnerunternehmen verschiedene APIs, mit denen sie ihre Datenerfassung anpassen und mParticle an die spezifischen Bedürfnisse ihres Unternehmens anpassen können.

Ein Beispiel ist die Profile-API, die es Kunden ermöglicht, programmgesteuert Benutzerprofile abzurufen, die mit den kanalübergreifenden Datenerfassungs- und Identitätsauflösungsfunktionen von mParticle erstellt wurden. Die bei der Abfrage dieser API abgerufenen Daten können Marken dabei helfen, schnell personalisierte Erlebnisse innerhalb oder kanalübergreifend zu erstellen.

Hier ist eine Beispielanfrage, die an die Profil-API gesendet werden könnte, um Daten in einem mParticle-Benutzerprofil abzurufen:

curl \
  -X GET \
  -H "Authorization: Bearer <access token>" \
"https://api.mparticle.com/userprofile/v1/<orgId>/<accountId>/<workspaceId>/
<mpid>?fields=device_identities,user_identities,user_attributes,
audience_memberships,attribution"

Und hier ist eine Beispielantwort auf diese Anfrage:

{
   "mpid": 9080350317581165000,
   "created_timestamp_ms": 1574704283462,
   "last_stored_timestamp_ms": 1575301484215,
   "is_opted_out": false,
   "limit_ad_tracking": null,
   "device_identities": [
       {
           "type": "android_id",
           "encoding": "none",
           "value": "8789c459016a94b0"
       },
       {
           "type": "google_advertising_id",
           "encoding": "none",
           "value": "481c8a31-7d5d-4d96-93a0-2de7427167fc"
       }
   ],
   "user_identities": [
       {
           "type": "customer_id",
           "encoding": "none",
           "value": "Example-Customer-mxr15"
       },
       {
           "type": "email",
           "encoding": "none",
           "value": "Example-Customer-mxr15@example.com"
       }
   ],
   "account_userattributes": null,
   "user_attributes": {
       "view_preference": "Dark Mode",
       "tp_age": "18-34",
       "tp_gender": "male",
       "last_purchase_category": "Home Decor",
       "churn_risk_score": "4",
       "ltv": "342.1",
       "$city": "New York",
       "$state": "NY",
       "$country": "USA",
       "$firstname": "Marky",
       "$lastname": "Mark"
   },
   "audience_memberships": [
       {
           "audience_id": 17918,
           "audience_name": "Decor Remarketing",
           "expiration_timestamp_ms": null
       }
   ]
}

Um diese API genauer zu erkunden, können Sie damit experimentieren Beispiel für eine Node-Anwendung, das die mParticle Profile API aufruft und das Ergebnis an einen nativen Client zurückgibt.

Hoffentlich hat dieser Beitrag Ihr Verständnis dieser beiden gängigen Methoden zum Teilen von Daten zwischen Anwendungen erweitert. Die gleiche Weisheit, die für alle Architekturen, Frameworks, Designmuster und Technologien in der Softwareentwicklung gilt, gilt auch für APIs und Webhooks: Alles hat seine Zeit und seinen Ort. Der Schlüssel, um das Beste aus beiden Tools herauszuholen, ist zu wissen, welches für die jeweilige Aufgabe geeignet ist.