Grundsätzliche Überlegungen für einen Web-Service – Teil 1

Stefan · 28.08.08, 22:17 Uhr · Konzepte, ZendFramework · Tags: PHP, REST, Web Service, ZF

Momentan arbeite ich an einem Projekt, das neben den normalen Arbeitsweisen eines CMS zur Verwaltung von Web-Inhalten (Ein-/Ausgabe der Inhalte), Teile dieser Inhalte einem ausgewählten und noch nicht näher spezifiziertem und erlauchtem Kreis von Partnern zur Verfügung gestellt werden sollen.

Vorweg gesagt: Bisher haben wir noch nicht eine Zeile Code geschrieben, sondern uns eher um grundsätzliche Fragen und Aufgabenstellungen Gedanken gemacht.

Die Ausgangssituation mit den wichtigsten Eigenschaften ist folgende:

• Einfache Anbindung zum Ursprungssystem:
  Das Ursprungssystem ist auf Basis von PHP und entgegen weitläufiger Meinungen ist PHP, wenn es gut programmiert wurde, auch sehr schnell, vor allem ab Version 5
• Größtmögliche Flexibilität bei der Steuerung von Inhalten:
  Angenommen, wir haben zukünftig verschiedene Partner mit unterschiedlichen Rechten (z.B. Partner a erhält Zugriff auf Titel, Kurzbeschreibung + andere Metainformationen des Inhaltes, Partner 2 erhält Komplettinhalte), so sollen diese sehr einfach verwalt- und pflegbar sein. Daneben soll es Filtermöglichkeiten des Inhaltes geben (wie eine Art Suche)
• Möglichst geringer Verwaltungsaufwand auf unserer Seite:
  Theoretisch kann es sein, dass ein Partner mehrere Projekte mit unterschiedlichen Inhalten realisieren will, dann wollen wir unsererseits keinen weiteren Aufwand treiben um dieses weitere Projekt zu ermöglichen.
• Wir wollen umfangreiche Statistiken:
  Wir wollen im Notfall genau wissen, welches Projekt von welchem Partner welche Daten wo verwendet und wann von uns erhalten werden. Daneben wollen wir wissen, wann ein Projekt gut läuft um gegebenenfalls auf schnelles Wachstum reagieren zu können. Wichtig ist in diesem Zusammenhang auch der Gedanke an eine eventuelle Monetarisierung, Wenn ein Projekt besonders viele Ressourcen bei uns in Anspruch nimmt.
• Wir wollen Stabilität und Sicherheit:
  Angenommen die Anzahl aktiver Projekte liegt im mittleren fünf-stelligen Bereich, dann spielt die Stabilität und Qualität der Bereitstellung unserer Daten eine große Rolle, da wir jederzeit eine gute und schnelle Datenqualität liefern wollen. Bei einer weitaus geringeren Anzahl Projekten spielt vor allem der Sicherheitsfaktor bereits eine große Rolle, da man grundsätzlich davon ausgehen muss, das s keine Software perfekt und ohne Sicherheitslücken ist – man hat sie einfach nur noch nicht gefunden. Um Datenmissbrauch oder eventuelle böswillige Attacken auf unsere Daten vorzubeugen und diese nicht in die gleiche Umgebung zu lassen, auf der unsere original Daten liegen, müssen verschiedene Vorkehrungen getroffen werden.

Das sind nur die wichtigsten Aufgabenstellungen, aber diese lassen bereits jetzt nur eine mögliche Lösung zu: Einen Web-Service.

Ein Web-Service kann alle diese Aufgaben bequem und clever lösen – wenn er richtig geplant wurde. Was also muss ein guter Web-Service können?

• Alle geplanten Inhalte liefern oder verarbeiten.
• Schnell und zügig erreichbar sein.
• Sicher sein.
• Eine einfache Programmierschnittstelle für Fremdentwickler zur Verfügung stellen.

Wir haben uns also verschiedene Lösungen angeschaut, z.B. auf Basis von SOAP, REST, WS_* oder etwas vollkommen neues. Etwas komplett neues verwarfen wir – zu aufwendig und nicht wirklich sinnvoll. SOAP? Zu groß, und zu schwer. Wir bewegen uns sowieso im Internet, das im HTTP-Protokoll recht einfach ist, warum also nicht auf REST (Representational State Transfer) setzen.

Viele Web-Services setzen auf REST, z.B. Amazon S3 und viele gut bekannte Web2.0-Paradebeispiele setzen bei ihrer API auf eine REST-ähnliche* Art (z.B. delicious.com oder flickr.com). Daneben arbeitet unser CMS, also Datenursprungssystem, auf Basis des Zend Framework, in dem beim Überfliegen der Klassen von uns auch eine REST-Klasse gesichtet wurde. Über die genaue Planung unseres Services und dass uns das Zend Framework gerade in der Zend_Rest Klasse enttäuschte, berichte ich in einem späteren Blogpost.

* REST-ähnlich, da der REST-Ansatz nicht komplett durchgezogen wurde