Mobile-Menu

Web-Service-APIs Contest – Teil 4 Anwendungsbeispiele mit REST

Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten

Immer mehr Anbieter von Web-Services wechseln von SOAP zu REST. Große Cloud-Anbieter wie Amazon und Azure bieten gar beides an, wenngleich sich der Fokus immer mehr zu REST verlagert. Wie REST-Aufrufe komponiert und die zugehörigen Responses analysiert werden, zeigt dieser Beitrag am Beispiel eines der zahlreichen Anbieter von Wetter-Apps, deren APIs ebenfalls meist auf REST basieren.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH
REST ist im vergleich zu SOAP reletiv einfach anzuwenden, da sich in der Regel diie gesamte Anfrage in der URL spezifizieren lässt.
REST ist im vergleich zu SOAP reletiv einfach anzuwenden, da sich in der Regel diie gesamte Anfrage in der URL spezifizieren lässt.
(Bild: Thomas Drilling)

Relativ populär ist z. B. die OpenWeather-API. Sie wird von zahlreichen Wetter-Apps wie z. B. Wetter.com verwendet, damit andere Web-Anwendungen Wetter-Daten über eine REST-Schnittstelle abrufen können.

Hierzu benötigt man zunächst den City-Code des gewünschten Ortes, z. B. „DE0000434“ für Augsburg. Dieser lässt sich auf der Wetter.com-Seite ermitteln, beispielsweise über eine Suchanfrage. Um festzustellen, ob man den richtigen Code hat, kann man einfach eine URL-basierte Suchabfrage an Wetter.com starten, beispielsweise mit:

http://www.wetter.com/wetter_aktuell/aktuelles_wetter/deutschland/Augsburg/DE0000434.html

Viele REST-API, wie die von OpenWeatherMap erfordern für Abfragen tempräre API-Keys.
Viele REST-API, wie die von OpenWeatherMap erfordern für Abfragen tempräre API-Keys.
(Bild: OpenWeatherMap)

Um eine Städtesuche oder eine Wettervorhersage für eine eigene Anwendung mit der OpenWeather-API und Wetter.com durchzuführen, muss man sich zunächst auf www.wetter.com registrieren. Nur dann kann man ein neues „Projekt“ für seine Anwendung erstellen.

Schließlich muss sich die Anfrage durch Übergabe mindestens dreier Parameter wie z. B. Projektname, City-Code und einer MD5-Checksumme im GET-Request der URL authentifizieren. Ferner benötigt man einen API-Key von http://openweathermap.org, wozu man sich auch dort als Nutzer registriert. Dieser bleibt jeweils für zehn Minuten gültig.

Das Zusammenbauen der Suchanfrage könnte in PHP z. B. so aussehen:

<?php
$sSearchURL = 'http://api.wetter.com/location/index'
$sProjectName = 'meinproject'
$sApiKey = 'secret'
$sSeachString = 'Augsburg'
$sChecksum = md5($sProjectName . $sApiKey . $sSeachString)
$sSearchURL = '/search/'. $sSeachString;
$sSearchURL = '/project/'. $sProjectName;
$sSearchURL = '/cs/'. $sChecksum;

Am Ende des Scripts kommt dann für $sSearchUrl ein solcher URL zustande:

http://api.wetter com/location/index/search/Augsburg/project/meinprojekt/cs/80368a04f1ed1abd73d39e3e533ce39b

Die Antwort analysieren wir aber anhand eines komplexeren Beispiels, das mehrere Treffer zulässt, wie z. B. die Suche nach Berlin. Gibt man den Länder-Code nicht an, würde Wetter.com auch das Berlin in New Hampshire (USA) finden.

http://api.wetter.com/location/index/search/Berlin/project/meinprojekt/cs/e5dafb3f2b2ac632a51d122644826cef

Die Antwort im JSON-Format könnte dann lauten:

   {
   search: {
      search_string: "Berlin",
      maxhits: 30,
      hits: 24,
      exact_match: false,
      credit: {
         info: "In order to use the free weather
         data from wetter.com you HAVE TO display
         at least two out of three of the
         following possibilities:
         text, link, logo",
         text: "Powered by wetter.com",
         ink: "http://www.wetter.com",
         logo: "Download at http://www.wetter.com/api/downloads/#logos"
      },
      result: [
      {
         adm_1_name: "Deutschland",
         city_code: "DE0001020",
         plz: "10115",
         quarter: "",
         adm_1_code: "DE",
         adm_2_name: "Berlin",
         adm_4_name: "Berlin",
         name: "Berlin"
      },
      {
         adm_1_name: "Vereinigte Staaten von Amerika",
         city_code: "US0NH0019",
         plz: "", quarter: "",
         adm_1_code: "US",
         adm_2_name: "New Hampshire",
         adm_4_name: "",
         name: "Berlin"
      },
      {
         adm_1_name: "Vereinigte Staaten von Amerika",
         city_code: "US0NJ0041", plz: "",
         quarter: "",
         adm_1_code: "US",
         adm_2_name: "New Jersey",
         adm_4_name: "",
         name: "Berlin"
      }
   ]
   }
}

Die OpenWeather-API lässt sich natürlich auch direkt ansteuern. Um die REST-Schnittstelle aufrufen zu dürfen, muss der registrierte Nutzer erneut einen API-Key anfordern. Der direkte REST-Aufruf zum Holen der Wettervorhersage für einen bestimmten Ort lautet dann:

http://api.openweathermap.org/data/2.5/forecast?id={City.ID}&APPID={APIKEY}

Statt des City-Codes lässt sich mit q= auch der City-Name verwenden. Auch die Kombination von Städtename und Ländercode durch Komma getrennt ist möglich, um Beispiele wie das doppelte Berlin auszuschließen. Die Country-Codes sind in ISO 3166 spezifiziert. Der zugehörige API-Call lautet dann z. B. für Augsburg:

http://api.openweathermap.org/data/2.5/forecast?q=Augsburg,De&APPID=ca9d175f389c46b262b56ef51ef64436

SOAP oder REST?

Bei der Entscheidung zwischen SOAP und REST ist trotz aller Vorzüge von REST auch zu bedenken, man zuerst schauen muss, welche Schnittstelle der gewünschte Web-Services anbietet. Einige Web-Services, wie Amazon AWS oder Microsoft Azure unterstützen zum Teil beides.

Es gibt auch eine große Zahl freier Web-Services, die man zum Ausprobieren heranziehen kann, darunter Free-Web-Services.com, WebserviceX.NET, SwaggerHub oder XMethods. Wer heute selbst einen Web Service anbieten will, startet in der Regel mit REST, allerdings klappt das nur dann ohne größere Schwierigkeiten, wenn das gesamte Software-Projekt auf der grünen Wiese startet. Hier noch einmal alle Vor- und Nachteile im Überblick:

Vorteile von SOAP

  • Unabhängig von Sprache, Plattform und Transportprotokoll. REST verwendet HTTP.
  • Funktioniert gut in verteilten Unternehmensumgebungen. REST realisiert immer eine direkte Punkt-zu-Punkt-Kommunikation).
  • Standardisiert.
  • Erweiterbar über WS* -Standards.
  • Eingebaute Fehlerbehandlung.
  • Automatisierung bei Verwendung mit bestimmten Sprachprodukten (WSDL).

Vorteile von REST

  • Einfacher zu bedienen und flexibler.
  • Keine, eventuell kostenpflichtige Tools erforderlich, um mit dem Web Service zu interagieren.
  • Kleinere Lernkurve.
  • Effizient: SOAP verwendet XML für alle Nachrichten, REST kann auch kleinere Nachrichtenformate wie JSON verwenden.
  • Orientiert sich näher in der Design-Philosophie näher an anderen Web-Technologien.
  • REST realisiert das Prinzip der losen Kopplung noch umfassender als SOAP
  • Dank der Zustandslosigkeit skalieren REST-Architekturen problemlos.

(ID:44614462)

Weiterführende Inhalte