Top 5 Fakten über Social Media APIs für Social Media Monitoring

Die Evolution der Social Media APIs (Quelle: Flickr)

Ein wichtiger Bestandteil jedes Sozialen Netzwerks aus technischer Sicht sind Programmierschnittstellen, auch APIs genannt. Über eine API können Daten aus den sozialen Netzwerken bezogen und in Apps oder Webseiten integriert werden.

Wir haben aus dem Social-Network-Dschungel die APIs der drei unserer Meinung nach für Social Media Monitoring interessantesten Sozialen Netzwerke verglichen und diese bezüglich der Brauchbarkeit analysiert:  Facebook, Twitter und Google+. Diese Netzwerke sind nicht nur sehr beliebt,  sie eignen sich auch sehr gut für eine Medienbeobachtung, da hier viel mittels Texten kommuniziert wird und nicht wie bei Flickr und Co. hauptsächlich via Bild-, Video- oder sonstigen multimedialen Inhalten, welche schwerer zu analysieren sind.

• Google+
  Das API des jüngsten Social Networks wurde erst im September 2011 veröffentlicht und befindet sich noch in einer frühen Phase. Es sind noch nicht alle Features abgedeckt und es ist noch sehr stark limitiert (Request Limits). Im Oktober 2011 wurde neben vielen anderen Features auch eine Suche über öffentliche Inhalte integriert.

• FB Graph API
  Das Facebook Graph API ist der Nachfolger des alten REST-API und wurde im April 2010 veröffentlicht. Die Idee ist dass über eine einheitliche URL (https://graph.facebook.com/ID), jedes Objekt im Facebook-Graphen über eine eindeutige ID abgefragt werden kann, sei es ein Benutzer, Event oder eine Seite. Ausserdem lassen sich durch weitere URLs verschiedene Beziehungen ausliefern. Das Graph API verfügt ebenfalls über eine Suche der öffentlichen Inhalte.

• Twitter Search API
  Das Twitter Search API ist bereits seit September 2006 Teil der Twitter Plattform. Es kann verwendet werden um einen Echtzeit-Index von Twitter-Tweets abzufragen. Dieser Index ist allerdings auf die letzten sechs bis neun Tage beschränkt, ältere Tweets können nicht abgefragt werden. Wichtig ist, dass die Suche auf Relevanz und nicht auf Vollständigkeit optimiert ist.
  Alternativ kann man mit dem Twitter Streaming API auch vollständige Nachrichtenströme real-time überwachen. Teil des Streaming APIs ist die ”Fire Hose“-Methode, welche es ermöglicht alle öffentlichen Statusmeldungen zu überwachen. Diese ist jedoch kostenpflichtig und für die meisten Einsatzzwecke, aufgrund der grossen Datenmengen, nicht praktikabel.

Dies sind unsere Bewertungskriterien:

• Dokumentation
  Die Dokumentation ist natürlich das Erste mit dem man in Berührung kommt. Eine optimale Dokumentation zeigt uns was und wie wir es mit dem API überhaupt tun können, gibt Aufschluss über mögliche Grenzen und Probleme und zeigt Best Practices auf.

  	Google+	Facebook	Twitter
  Pro	API Explorer in die Dokumentation eingebunden	Rechte werden auf Feldebene dokumentiert	Usage Guide mit Best Practices, Search Operators und Limits
  Kontra	Nur wenige Beispiel Request-/Response-Zyklen	lückenhaft, inkonsistent bei Feldbezeichnung und -inhalten teilweise Felder nicht dokumentiert keine Dokumentation von Datentypen Maximale Records/Page schlecht dokumentiert	keine Dokumentation von Datentypen
  Neutral	übersichtlich, stukturiert Dokumentation pro Entität mit Properties, Bespreibung, Datentypen und Beispiele Konsequent RESTful: Resource Representations	Saubere Gliederung: Getting Started, Core Concepts, SDK uvm. Pro Object eine Dokumentation mit Feldern, Beschreibung, Rechten	Feldbezeichnung, Beschreibung und Beispiele übersichtlich aufgelistet Bespiele für Request-/Response Zyklen
  Bewertung	++	–	+

  WINNER: Die Dokumentation von Google+ lässt keine Fragen offen.

• Datenstruktur
  Hier wird die Brauchbarkeit der Datenstruktur bewertet. Ist es in einem Datensatz sofort klar, dass es sich um einen Post, Kommentar oder Foto handelt? Ist ein klares Muster zu erkennen? Haben die Felder die richtigen Bezeichnungen, Datentypen und Inhalte?

  	Google+	Facebook	Twitter
  Pro	Direktlinks zu Aktivitäten und Subjekten	Jedes Objekt im Social Graph hat eine eindeutige ID und URL	Metadaten Extraktion (tweet-entities)
  Kontra	-	keine URL pro Entität, nur IDs teilweise haben Aktivitäten kein Verb (Story) Mehrfachbelegung von Feldern mit unterschiedlichem Inhalt teilweise dienen Inhalt der GUI Steuerung	keine URL pro Entität, nur IDs
  Neutral	Jede Aktivität hat ein Subjekt, Verb und Objekt – das API spiegelt das genau so als Datenstruktur wieder Reichhaltige Strukturierung von Assets als Attachements	Jede Aktivtät hat ein Subjekt und Objekt, nur teilweise ein Verb	Jede Aktivität hat ein Subjekt und Objekt, Verlinkung von Subjekten via @
  Bewertung	++	–	+

  WINNER: Google+ fühlt sich sehr natürlich an: Subject-Verb-Object, abgebildet im API.

• Features
  Bewertete Features beinhalten zum Beispiel, wie stark sich die Ergebnis-Menge anpassen lässt, wie viele Datensätze wir pro Anfrage erhalten können und ob es einen Paging-Mechanismus gibt, um ältere Datensätze zu laden. Ferner ist es uns wichtig, ob die Ergebnismenge auf ein bestimmtes Land oder Sprache reduziert werden kann.

  	Google+	Facebook	Twitter
  Pro	Partial Responses OrderBy-Parameter	Bis zu 500 Records/Page möglich	Locale-Parameter Tweet-Entites ab-/zuschaltbar Geocodes Paging bis zu ca. 1500 Tweets
  Kontra	Maximal 20 Aktivitäten/Page	Request-Parameter (since/until) für das Paging (previous/next) wiedersprüchlich API interpretiert den Request Header: Accept-Language Locale bedeutet für viele Sprachräume mehrere Requests (de_DE,  de_CH, de_AT)	Such-Index begrenzt auf 6-9 Tage – Paging begrenzt Maximal 100 Tweets/Page
  Neutral	Paging Sprachparameter	Paging Locale-Parameter	Paging Sprachparameter
  Bewertung	+	-	+

  WINNER: Google+ und Twitter. Google + verfügt über innovative Funktionen, bislang noch stark limitiert, Twitter bietet eine perfekte Metadaten-Extrahierung.

• Limits
  In der Regel werden API’s mit Limits versehen, um die Server nicht zu überlasten. Gesteuert wird dies beispielsweise durch ein Maximum an Requests pro Sekunde oder Requests pro Tag. Hier wird bewertet, wie stark diese Limits das Crawlen beeinflussen und ob diese Limits sauber dokumentiert sind.
  
  

  	Google+	Facebook	Twitter
  Pro	-	kein API Key	kein API key
  Kontra	bislang starke Reglementierung bezüglich Maximalwerte benötigt API Key	-	Keine Resultate, die älter als 9 Tage sind Query Komplexität beschränkt Beschränkung auf Request von einer IP Adresse, Limits nicht dokumentiert
  Neutral	max. 20 Posts/Request max. 1000 Requests/Tag	bis zu 500 Posts/Request 100 Mio. Requests/Tag 1 Request pro Sekunde	keine Beschränkung auf Request/Stunde o.ä.
  Bewertung	–	++	+

  WINNER: Facebook kann den meisten Throughput garantieren.

• Fehlerbehandlung
  Werden Fehler korrekt mit HTTP-Status Codes beantwortet, bspw. beim Überschreiten von Limits?

  	Google+	Facebook	Twitter
  Pro	Status Code 400 bei falschen Parametern	-	-
  Kontra	-	Status Code 500 bei falschen Parametern	Status Code 403 bei falschen Parametern
  Neutral	Kein HTTP Status Code 200 bei falschen Parametern	Kein HTTP Status Code 200 bei falschen Parametern	Kein HTTP Status Code 200 bei falschen Parametern
  Bewertung	+	o	o

  WINNER: Google+ hebt sich durch korrekte Fehlerbehandlung ab.

Fazit

Wir sagen: Google+ API is Facebook API done right!