Wie implementiere ich eine eigene Web-API?

[Eddie]

Hallo allerseits,

ich bin gerade dabei, eine kleine Webanwendung zu programmieren - relativ formularlastig. Jetzt überlege ich mir, ob es nicht vielleicht Sinn machen würde, diese Anwendung über eine Web-API auch anderen Seiten zur Verfügung zu stellen (konkret erstmal Seiten von mir).

Dafür bräuchte ich ja sowas wie eine Web-API oder einen Web-Service (Stichtworte SOAP, RPC, Corba...). Nur ist mir die Funktionsweise in meinem konkreten Fall nicht wirklich klar, und da bräuchte ich eure Hilfe!

Nehmen wir mal eine Vereinfachung meines Problems: ein Formular, das es erlaubt, eine Grafik hochzuladen und auf eine Wunschgröße zu verkleinern. Dafür brauche ich 2 Formularelemente, richtig?
Ausserdem habe ich 3 Schritte bis zum fertigen Bild:

1. ein leeres Formular
2. ggf. nochmal das Formular mit Fehlercheck
3. das fertige Bild

Da ich das ja aber per Webservice mache, muss sich meine lokale Software (Client) das Ergebnis aller 3 Schritte vom Server holen. So wie ich das jetzt sehe, muss ich dafür auf jedem Client mindestens

• die Ablauflogik implementieren (also die Logik dieser 3 Schritte)
• wissen, welche Formulardaten es gibt, und diese dann an den Server schicken
  Oder sehe ich das falsch? Jedenfalls wäre ich euch dankbar, wenn ihr mir ein wenig Klarheit in das Dunkel bringen könntet!

Eddie

P.S.: ich hoffe, ich habe mich halbwegs verständlich ausgedrückt, wenn nicht, fragt bitte nach!

[Tom]

Hello,

Die Trennung von Client und Server ist doch schon mal eine gute Voraussetzung. Die solltest Du auch nicht aufbohren. Der Client muss also nicht "wissen", was er zu tun hat, sondern die vorgelegten Schritte einfach nur abarbeiten.

Damit Du keine abgebrochenen Vorgänge erzeugst, muss aber auf dem Server eine intelligente Vorgangsverarbeitung existieren.

Willst Du denn auch tatsächlich verteilte Anwendungen erstellen? Oder soll alles auf einem Server ausgeführt werden?

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Eddie]

Hey Tom,

Die Trennung von Client und Server ist doch schon mal eine gute Voraussetzung. Die solltest Du auch nicht aufbohren.

Genau, es wäre schön, wenn der Client so wenig wie möglich zu tun hätte, und möglichst viel beim Server liegt.

Der Client muss also nicht "wissen", was er zu tun hat, sondern die vorgelegten Schritte einfach nur abarbeiten.

Bedeutet das, dass der Server dem Client die Schritte vorgibt? Aber dann braucht doch der Client wieder eine Logik, um diese Vorgaben abzuarbeiten :-(

Damit Du keine abgebrochenen Vorgänge erzeugst, muss aber auf dem Server eine intelligente Vorgangsverarbeitung existieren.

Wie meinst du das? Ein abgebrochener Vorgang macht doch erst dann was aus, wenn mitten im HTTP-Request was schief geht. Das muss natürlich ausgeschlossen sein, klar. Aber wenn der User mitten in Schritt 2 feststellt, dass er keine Lust mehr hat, ist das doch nicht weiter schlimm?

Willst Du denn auch tatsächlich verteilte Anwendungen erstellen? Oder soll alles auf einem Server ausgeführt werden?

Nein, ich haette einen Bildverarbeitungsserver ("BVS"), auf den dann bspw. www.umdiewelt.de zugreift. Auch ein direkter Zugriff mittels HTTP auf den BVS wäre möglich, der Besucher würde dann dort dasselbe Formular vorfinden.
Ich will das deshalb getrennt, weil die Serverlast u.U. recht hoch sein wird (hoffe ich zumindest). Dann kann ich das Ganze ggf. sehr einfach auf einen separaten Server legen.

Bin mittlerweile am Ueberlegen, ob ich nur Schritt 1 per Web-Api realisiere (also Erzeugen des Formulars), und den Rest (Schritt 2 und 3) per Ajax. Das muesste ja auch gehen, die Client-Server-Logik waere dann sehr einfach, das mit Ajax entsprechend komplizierter.
Du siehst, ich lote noch meine Moeglichkeiten aus :-)

Eddie

[molily]

Hallo,

Nein, ich haette einen Bildverarbeitungsserver ("BVS"), auf den dann bspw. www.umdiewelt.de zugreift. Auch ein direkter Zugriff mittels HTTP auf den BVS wäre möglich, der Besucher würde dann dort dasselbe Formular vorfinden.

Das klingt ja eher nach einer einfachen Framing-Lösung als nach einem API. Welche Kommunikation zwischen den drei Beteiligten (Nutzer/Browser, BVS, umdiewelt) willst du über den API regeln?

Ich will das deshalb getrennt, weil die Serverlast u.U. recht hoch sein wird (hoffe ich zumindest). Dann kann ich das Ganze ggf. sehr einfach auf einen separaten Server legen.

An welchen Server soll die POST-Anfrage gehen, bei der die Datei hochgeladen wird? Das Resultat, die verkleinerte Grafik, brauchst du letztlich auf umdiewelt, einem anderen Rechner als BVS?

Bin mittlerweile am Ueberlegen, ob ich nur Schritt 1 per Web-Api realisiere (also Erzeugen des Formulars)

Mir ist noch nicht klar, was du unter Web-API verstehst. Welche Informationen sollen ausgetauscht werden? Auf dem BVS liegt das HTML-Formular und du willst es dem Browser ausliefern, der umdiewelt anfragt? So ein Einbetten würde ich noch nicht als API bezeichnen. Bis dahin ist es wohl recht trivial.

und den Rest (Schritt 2 und 3) per Ajax. Das muesste ja auch gehen, die Client-Server-Logik waere dann sehr einfach, das mit Ajax entsprechend komplizierter.

Formularvalidierung kannst du mit AJAX einfach gestalten, solange das Script zu einem Dokument gehört, das auf demselben Server liegt, der per AJAX kontaktiert wird (mit fremden Servern ginge es auch, aber schwieriger). Das Übertragen des Formulars samt Datei muss klassisch erfolgen, also brauchst du an dieser Stelle ein gewöhnliches Formular.

Suchst du jetzt nach einer Schnittstelle zwischen der serverseitigen Logik auf umdiewelt und derselben auf dem BVS, sodass das Formular über umdiewelt aufgerufen werden kann, die Formulardaten vom Browser zunächst an umdiewelt gesendet werden und die Grafik an den BVS weitergegeben wird, der seinerseits die verkleinerte Grafik zurückgibt? umdiewelt dient dann sozusagen als Proxy für die Anfragen vom Client zum BVS.

Oder kann das Hochladen ruhig öffentlich (bzw. über Frames) über den BVS laufen, aber umdiewelt braucht letztlich die verkleinerte Grafik?

Ich verstehe noch nicht, was du dir vorstellst.

Mathias

[molily]

Hallo,

Dafür bräuchte ich ja sowas wie eine Web-API oder einen Web-Service (Stichtworte SOAP, RPC, Corba...).

»REST« sollte erst einmal das Stichwort sein, wenn du es einfach haben willst. Das heißt Arbeiten mit den Standardaktionen von HTTP, vor allem GET und POST sowie einem »Interface« in Form von URIs, die bestimmte Ressourcen beschreiben.

Nehmen wir mal eine Vereinfachung meines Problems: ein Formular, das es erlaubt, eine Grafik hochzuladen und auf eine Wunschgröße zu verkleinern. Dafür brauche ich 2 Formularelemente, richtig?

Sinnigerweise stellt deine API eine Methode »Grafik einliefern« zur Verfügung. Diese gibt dann die verkleinerte Grafik zurück oder eine Fehlermeldung.

Ausserdem habe ich 3 Schritte bis zum fertigen Bild:

1. ein leeres Formular
2. ggf. nochmal das Formular mit Fehlercheck
3. das fertige Bild

Ein Server ist m.M.n. nicht für die Validierung der Eingabedaten zuständig. Die eingelieferten Daten haben korrekt zu sein. Natürlich kannst du die Fehlermeldung im oben genannten Modell ausbauen oder eine eigene Methode zur Validierung bereitstellen. Das halte ich allerdings nicht für nötig.

Da ich das ja aber per Webservice mache, muss sich meine lokale Software (Client) das Ergebnis aller 3 Schritte vom Server holen.

Du hast ein fest definiertes Interface deines Web Services. Das definiert das Formular (Felder und Datentypen, mögliche Werte, Vorgaben usw.) sowie die Übertragungsmethoden. Dieses kennt der Client von Natur aus und kann also das »leere Formular« ohne Zugriff auf den Server darstellen.

Eine Verbindung mit dem Server sollte m.E. erst aufgenommen werden, wenn die Formulardaten übertragen werden. Da der API auch die Anforderungen an die Eingabedaten definiert, kann der Client vor jeder Kontaktaufnahme eine grundlegende Validierung vornehmen. Nur die letztliche Gültigkeitsprüfung, die naturgemäß nur dem Server möglich ist, sollte auch dort vorgenommen werden.

Mathias