PHP Backend allgemein gestalten für AJAX/Flash/Silverlight etc.

[INC.]

Hallo!

Wir sind gerade dabei ein Projekt umzusetzen, können uns aber bei der Technologie für das Frontend, bzw. das Benutzerinterface einfach nicht eintscheiden. Also Ob Flash AJAX+HTML oder ganz was anderes.

Da uns aber langsam die Zeit wegrennt haben wir nun den Plan, das PHP-Backend in code umzusetzen. Also die ganzen Schnittstellen zur Datenbank, Userverwaltung und so weiter.

Die Idee dahinter ist, das PHP-Backend so allgemein zu gestalten, dass wir hinterher jede beliebige Technologie davorhängen können, sei es Flash oder Ajax oder ...

So, jetzt mal zum Anliegen:

Wie würdet ihr den PHP-Teil nach außen hin gestalten, so dass Ajax als auch alles andere möglichst einfach damit kommunizieren kann?

Die einfachste Lösung wäre ja, dass ein PHP-File einfach per POST oder GET Daten entgegennimmt und gleichzeitig sich selbst als Antwort liefert, z.B. per XML Ausgabe.
Aber irgendwie nicht sehr elegant.

Dann gibt es ja auch noch Dinge wie SOAP und REST. Klingt schon vernünftiger. Ich frage mich nur, ob der Aufwand gerechtfertigt ist. Wenn man sich zum Beispiel jQuery anschaut, dann verlangen die Methoden dort auch nur den Namen des aufzurufenden PHP-Files statt irgendwelche komplexeren Dienste.
jQuery hat mich also von dem SOAP/REST Gedanken wieder etwas abgebracht.

Es sollte halt einfach eine möglichst optimale und saubere Schnittstelle für diverse Technologien werden, ich hoffe, man muss dabei nicht zuviele Kompromisse eingehen.

Vielleicht habt ihr ja einen Einfall, danke vielmals.

[onemorenerd]

Wir sind gerade dabei ein Projekt umzusetzen, können uns aber bei der Technologie für das Frontend, bzw. das Benutzerinterface einfach nicht eintscheiden. Also Ob Flash AJAX+HTML oder ganz was anderes.

Dann solltet ihr das erstmal entscheiden. Aus welchem Grund wollt ihr das offen halten?

[Hopka]

Der Unterschied zwischen dem hier:

Die einfachste Lösung wäre ja, dass ein PHP-File einfach per POST oder GET Daten entgegennimmt und gleichzeitig sich selbst als Antwort liefert, z.B. per XML Ausgabe.

und REST ist kleiner, als dir vielleicht bewusst ist.

Wie ich es machen würde (und schon gemacht habe), ist mir eine API zu definieren. Das ist letztenendes auch nicht mehr als ein (oder mehrere) PHP-Files, die JSON oder XML via GET oder POST entgegennehmen und dann auch JSON oder XML zurückliefern. Dazu noch ein bisschen was für Fehlerbehandlung und gut ist.

Wenn JSON für dich OK ist, dann guck dir mal JSON-RPC an. Dafür gibt es schon JavaScript-Clients (auch für jQuery) und PHP-Server (der vom Zend Framework ist aber nicht so gut).

[INC.]

Danke schonmal euch beiden.

Dann solltet ihr das erstmal entscheiden. Aus welchem Grund wollt ihr das offen halten?

Weil ich der Meinung bin, dass Flash und Konsorten eher auf einem absteigenden Ast sind, wenn man bedenkt, dass die JS-Engines der aktuellen Browser performancetechnisch ständig zulegen. Wenn jetzt mit HTML5 auch noch Flashvideoplayer überflüssig werden, dann ist das Einsatzgebiet von Flash gleich nochmal dezimiert. Ein Kollege sieht das aber anders, und Flash bzw. Flex hat schon den Reiz der Einfachheit.
Aber diese Diskussion gehört hier nicht her

Abgesehen davon: in der Softwareentwicklung versucht man doch in vielen Gebieten, das GUI vom Rest so abzukoppeln, dass es austauschbar bleibt. Warum nicht auch hier?

Der Unterschied zwischen dem hier:

und REST ist kleiner, als dir vielleicht bewusst ist.

Stimmt, das war mir noch garnicht so bewusst. die Kurzbeschreibung für REST lautet eigentlich immer gleich, und zwar dass jeder Dienst seine eigene PHP-Datei bekommt. Ob da jetzt noch mehr dahintersteckt, danach hab ich mich noch nicht erkundigt,

Wenn JSON für dich OK ist, dann guck dir mal JSON-RPC an. Dafür gibt es schon JavaScript-Clients (auch für jQuery) und PHP-Server (der vom Zend Framework ist aber nicht so gut).

JSON wäre super. Fragt sich nur, ob man die Schnittstelle damit allgemein hält, Flex ist eher auf XML fokussiert, wenn meine Recherchen nicht völlig daneben sind.

Was ich noch nicht ganz verstanden habe: Was genau bringt dann der JSON-RPC PHP-Server?

Auf der JSON-RPC Seite wird unter "PHP-Implementierungen" unter anderem JSON-PHP vorgeschlagen. Da wird der output so generiert:

$value = array(1, 2, 'foo');
$output = $json->encode($value);
print($output); 

Und den Input bekomt man so

$input = $GLOBALS['HTTP_RAW_POST_DATA'];
$value = $json->decode($input); 

sieht ja echt einfach aus. Aber für was genau braucht man dabei diesen Server? Oder wäre das bereits ein Server?

Danke!

[AmicaNoctis]

die Kurzbeschreibung für REST lautet eigentlich immer gleich, und zwar dass jeder Dienst seine eigene PHP-Datei bekommt.

Das ist nicht ganz richtig. Jede Ressource (also Informationseinheit) hat eine eigene eindeutige Adresse. Mit Request Funneling per mod_rewrite kann man das aber über ein einziges PHP-Skript abwickeln (den Controller, wenn man MVC-konform arbeitet). In meinem ReST-Framework mache ich das so, hab aber für (fast) jede Ressource eine eigene Klasse, die dann instanziiert wird und den Request verarbeitet.

Ein weiterer Vorteil von ReST ist, dass du unterschiedliche Repräsentationen liefern kannst, je nach Anfrage. Also kannst du mit derselben Ressource mal XML, mal JSON, mal SWF oder auch eine komplette HTML-Seite ausliefern. Wenn du also das Frontend technologisch austauschbar halten willst, ist ReST aus meiner Sicht die optimale Variante.

Gruß,

Amica

[Hopka]

Der Server würde im Prinzip eine PHP-Klasse nehmen und deren Funktionen bereitstellen. D.h. er läuft als PHP-Script, dass Anfragen im JSON-RPC Format entgegen nimmt, den Funktionsnamen und die Parameter dekodiert/umwandelt, damit die entsprechenden Funktionen der Klasse aufruft und dann die Rückgaben der Funktionen wieder nach JSON umwandelt und zurück liefert. Zusätzlich kann er noch eine Liste der Funktionen bereitstellen, die dem Client die Arbeit erleichtern.

Aber du hast schon Recht, es geht auch ohne. Ist nur ein bisschen mehr Arbeit wenn man es zu Fuß macht und man muss ein wenig Erfahrung haben um es "sauber" hinzukriegen.

[INC.]

Das ist nicht ganz richtig. Jede Ressource (also Informationseinheit) hat eine eigene eindeutige Adresse. Mit Request Funneling per mod_rewrite kann man das aber über ein einziges PHP-Skript abwickeln (den Controller, wenn man MVC-konform arbeitet). In meinem ReST-Framework mache ich das so, hab aber für (fast) jede Ressource eine eigene Klasse, die dann instanziiert wird und den Request verarbeitet.

Wieder was gelernt, klingt höchst interessant. mod_rewrite ist aber optional, oder?

rest.php?service=xy

Da bräuchte man auch nur eine PHP-Datei zur Verwaltung. Oder ist die Adresse nicht wirklich eindeutig genug, falls nein, wie würde man das per mod_rewrite eindeutig machen?

rest/service/xy zum Beispiel?


Ansonsten hoffe ich, dein vorgehen verstanden zu haben. du hast eine "Manager-Klasse", die per GET/POST Parameter empfängt, das entsprechende PHP-Submodul lädt, die Parameter übergibt, die Antwort vom Submodul zurückbekommt und es dann als XML/JSON ausgibt?

Hm, falls ich das richtig verstanden habe, dann behalte ich das im Hinterkopf. Klingt einfach aber doch flexibel.

Wie könnte man das mit dem Submodul laden am besten lösen? Auch wenn das PHP-OOP nicht der Knüller ist, Interfaces gibts ja zum Glück auch. Da könnte man wenisgtens schonmal den Rahmen der Submodule festlegen.
Aber weiter? Das einfachste und naivste was mir gerade einfällt wäre ein switch-case, was die Parameter der URL nach dem Modul abfragt und dann im case-Teil eine neue Instanz davon erstellt, wenn was zutrifft. Der Rest unter dem switch-case kann man ja dank dem Interface allgemein halten.

Ich weiß, dass modulare Programmierung im wesentlichen viel komplizierter abläuft, mit einem Server bei dem sich die "Plugins" registrieren müssen etc. aber man muss ja nicht mit Kanonen auf Spatzen schießen.

Der Server würde im Prinzip eine PHP-Klasse nehmen und deren Funktionen bereitstellen. D.h. er läuft als PHP-Script, dass Anfragen im JSON-RPC Format entgegen nimmt, den Funktionsnamen und die Parameter dekodiert/umwandelt, damit die entsprechenden Funktionen der Klasse aufruft und dann die Rückgaben der Funktionen wieder nach JSON umwandelt und zurück liefert. Zusätzlich kann er noch eine Liste der Funktionen bereitstellen, die dem Client die Arbeit erleichtern.

Wenn ich nicht falsch liege, dann wäre der Server ja in etwa das, was AmicaNoctis als Controller benutzt. Also eine Verwaltungseinheit, die sich Module schnappt und füttert sowie ausliest?


Danke

[AmicaNoctis]

Du verwechselst immer noch Dienst (=Service) und Ressource. Der Dienst ist das ganze Ding und kann schlimmstenfalls aus tausenden von Ressourcen bestehen.

Das mit deinem Switch-Vorschlag kann man auch über eine XML-Ressourcendefinition lösen oder aus einer DB abfragen. So ist es leichter wartbar, als wenn man es im irgendwo im PHP-Code festlegt. Ansonsten trifft das meine Herangehensweise schon in weiten Teilen.

Ich hab in der Tat so eine "Manager"-Klasse, die ein Request-Objekt erzeugt und mit allen Request-Headern und Daten füllt. Die einzelnen Ressourcen implementieren mein IRestResource-Interface und damit den CRUD-Methodensatz plus OPTIONS. Jede dieser Methoden erwartet das Request-Objekt und liefert ein Response-Objekt zurück, das dann vom Controller je nach Accept-Header an eine View-Klasse übergeben und dort in eine konkrete Repräsentation (z. B. XML oder JSON) serialisiert wird. Das wird dann zum Browser gesendet.

[INC.]

Du verwechselst immer noch Dienst (=Service) und Ressource. Der Dienst ist das ganze Ding und kann schlimmstenfalls aus tausenden von Ressourcen bestehen.

Stimmt, ich glaub ich hab's jetzt dank der Erklärung aber jetzt doch begriffen
Wo habe ich das im obigen Post verwechselt? Ist eigentlich auch egal, ich wundere mich nur weil du zu dem mod_rewrite nichts geschrieben hast, also auch nicht ob es falsch ist.

Das mit deinem Switch-Vorschlag kann man auch über eine XML-Ressourcendefinition lösen oder aus einer DB abfragen. So ist es leichter wartbar, als wenn man es im irgendwo im PHP-Code festlegt. Ansonsten trifft das meine Herangehensweise schon in weiten Teilen.

Ich hab mir schon gedacht dass das Müll ist, wenn man immer an der Klasse selbst rumfummeln muss. Das mit der XML klingt aber gut, hast du einen Link oder ähnliches, wo das gezeigt wird?
Mir fiel vorher einfach keine Möglichkeit ein, anhand einer Liste zu entscheiden, welches Objekt instanziert werden muss. Google spuckt mir zu "XML Ressourcendefinition PHP" leider wenig aus.

Ich hab in der Tat so eine "Manager"-Klasse, die ein Request-Objekt erzeugt und mit allen Request-Headern und Daten füllt. Die einzelnen Ressourcen implementieren mein IRestResource-Interface und damit den CRUD-Methodensatz plus OPTIONS. Jede dieser Methoden erwartet das Request-Objekt und liefert ein Response-Objekt zurück, das dann vom Controller je nach Accept-Header an eine View-Klasse übergeben und dort in eine konkrete Repräsentation (z. B. XML oder JSON) serialisiert wird. Das wird dann zum Browser gesendet.

Klingt wirklich gut. Ich werde mich demnächst auch mal an sowas versuchen
Noch eine Frage zu REST: Wenn ich jetzt das ganze so implementiert habe, dass jede Ressource eine eindeutige Adresse besitzt und eben auch die Dinge macht, die du beschrieben hast.. hab ich dann schon etwas, was sich REST-Service schimpfen darf?
Wenn ich nämlich analog nach PHP und Soap stöbere, dann reden die Leute nur von SOAP, wenn auch PHP Soap oder etwas entsprechendes verwendet wurde. aber etwas wie PHP REST scheint es offiziell ja garnicht zu geben, was man verwendet könnte.

[AmicaNoctis]

Zum Thema mod_rewrite: Man muss es nicht damit machen, aber ohne mod_rewrite programmierst du dich tot, weil du dann für jede Ressource ein PHP-Skript bräuchtest. Sobald du aber dynamische Ressourcen hast, geht das sowieso nicht mehr (Beispiel: Bild eines Artikels im Warenkorb von Benutzer Manni Müller: http://example.com/shop/user1234/warenkorb/artikel2345/bild3456/).

PHP ReST ist kein fertiges Framework, genausowenig wie ReST selbst. ReST ist HTTP, wie es mal gedacht war und mit zusätzlichen Constraints, die einerseits verhindern, dass dieses Protokoll so missbraucht wird, wie es seit den 90ern passiert und andererseits forcieren, dass sinnvolle Features wieder eine Bedeutung erlangen, die in Vergessenheit geraten sind.

Wenn du einen ReSTful Webservice schreibst, solltest du also zuallererst das HTTP gut kennen, vor allem die Terminologie drumherum, Response Codes, Header, ... Als zweites solltest du dich über die ReST-Constraints informieren. Dann kommt die implementatorische Fleißarbeit.

Mein Webservice ist z. B. from the scratch geschrieben, also ohne Framework oder so. Alles, was ich darüber erzählen könnte, ist also nur eine Möglichkeit. Andererseits gibt es jetzt auch nicht sehr viel, was man anders machen könnte, ohne die ReSTfulness zu verletzen.

Gruß,

Amica

[wahsaga]

Zur Ergänzung, der Vollständigkeit halber:

Zum Thema mod_rewrite: Man muss es nicht damit machen, aber ohne mod_rewrite programmierst du dich tot, weil du dann für jede Ressource ein PHP-Skript bräuchtest. Sobald du aber dynamische Ressourcen hast, geht das sowieso nicht mehr (Beispiel: Bild eines Artikels im Warenkorb von Benutzer Manni Müller: http://example.com/shop/user1234/warenkorb/artikel2345/bild3456/).

Path Info bzw. Symlinks (zweitere natürlich nicht für das letztgenannte Szenario) könnte man noch als Alternativen oder besser Notnägel, falls mod_rewrite nicht zur Verfügung stehen sollte, einsetzen (aber das sollte bei einem Projekt dieser Grössenordnung ja gar nicht zur Debatte stehen müssen).

Ganz Verwegene nutzen auch mal gerne ErrorDocument 404, um darüber ein Script anzustossen, dass alle Requests auf nicht existente Ressourcen abfängt, und aus den Umgebungsvariablen dann das gewünschte Ziel/Aktion extrahiert. Aber auch das ist extrem unsauber; nicht zuletzt, weil man sich damit das Error-Log mit „falschen“ Fehlermeldungen zusch***t.


mod_rewrite ist schon das Mittel der Wahl für solche Zwecke (zumindest, wenn man sich auf einem Apache-Webserver befindet).

[AmicaNoctis]

mod_rewrite ist schon das Mittel der Wahl für solche Zwecke (zumindest, wenn man sich auf einem Apache-Webserver befindet).

Naja, inzwischen bin ich davon überzeugt, dass Apache die zweite Wahl ist. Die erste Wahl ist imho ein nativer multithreaded PHP-Webserver.

[PHP-Desaster]

Wir nutzen für unsere RIAs ExtJS und für den Austausch zwischen PHP-Backend und Client-Applikation deren Format Ext.Direct. Das Backend ist allerdings so gestrickt, dass die eigentliche Datenrepräsentation abstrahiert wird, d.h. wir haben die gleichen Services auch mit einer RESTful JSON API und einer SOAP Schnittstelle versehen. Ist auf jeden Fall einen Blick wert und kann meiner Meinung nach mit so etwas wie Flex locker mithalten.

[INC.]

Ich bins nochmal kurz, bevor ich jetzt was ich die Richtung mache nochmal was zum Vorgehen:

PHP ReST ist kein fertiges Framework, genausowenig wie ReST selbst. ReST ist HTTP, wie es mal gedacht war und mit zusätzlichen Constraints, die einerseits verhindern, dass dieses Protokoll so missbraucht wird, wie es seit den 90ern passiert und andererseits forcieren, dass sinnvolle Features wieder eine Bedeutung erlangen, die in Vergessenheit geraten sind.

Wenn du einen ReSTful Webservice schreibst, solltest du also zuallererst das HTTP gut kennen, vor allem die Terminologie drumherum, Response Codes, Header, ... Als zweites solltest du dich über die ReST-Constraints informieren. Dann kommt die implementatorische Fleißarbeit.

Damit hab ich noch Probleme. Plötzlich sprichst du HTTP und seine Funktionsweise in allen Details an - wenn man sich bei Wikipedia nach Rest umschaut, dann macht das auch durchaus Sinn (PUT, OPTIONS, DELETE kannte ich bisher nur vom Hörensagen).

Allerdings bin ich jetzt im ganzen Thread davon ausgegangen, dass man das garnicht braucht - meinen Request an den Server kann ich ja mit Parametern bestücken und somit alles erreichen was ich will. Andererseits kommt die Antwort als XML oder JSON, vom Server generiert, und dort kann doch auch drin stehen was will. Mir fällt spontan nichts ein, was nicht gehen sollte.

Wozu braucht man also noch Kentnisse über HTTP an sich - ich will jetzt wirklich nicht wie ein Banause klingen, sondern frage mich nur, ob ich mir den Aufwand nicht aufsparen kann für mein Vorhaben, oder ob das ganze dann zu unsauber wird.

Der Kernpunkt von Rest, "jede Ressource mit einer eigenen URI anzusprechen", ist ja auch ohne HTTP-Kentnisse realisierbar. Der Aufruf der Ressource und die Datenübertragung mittels GET/POST hatte ich ja ebenfalls geplant, aber bin bisher davon ausgegangen, dass das völlig ausreichend ist.


Danke nochmals für die zahlreichen Antworten.

PS: AmicaNoctis, könntest du noch ganz kurz einen Satz über die XML-Ressourcendefinition verlieren? Finde wie gesagt nichts dazu, aber kompliziert kann es ja nicht sein. Es ging dabei oben um die automatische, gleichzeitig dynamische Erstellung der passenden Objekte ohne hardcoded PHP-File.

[AmicaNoctis]

Allerdings bin ich jetzt im ganzen Thread davon ausgegangen, dass man das garnicht braucht - meinen Request an den Server kann ich ja mit Parametern bestücken und somit alles erreichen was ich will. [...]

Wozu braucht man also noch Kentnisse über HTTP an sich - ich will jetzt wirklich nicht wie ein Banause klingen, sondern frage mich nur, ob ich mir den Aufwand nicht aufsparen kann für mein Vorhaben, oder ob das ganze dann zu unsauber wird.

Das wird imho zu unsauber. Mit GET und POST alleine wird es niemals RESTful werden. Ohne DELETE kann man nichts löschen und ohne PUT nichts aktualisieren. Das wird zwar oft alles über POST gemacht, aber dann ist es eben nicht RESTful.

Der Kernpunkt von Rest, "jede Ressource mit einer eigenen URI anzusprechen", ist ja auch ohne HTTP-Kentnisse realisierbar.

Das ist ein Kernpunkt von vielen. Sich nur auf diesen zu stützen und alles andere zu vernachlässigen, ist wieder nicht RESTful. Nimm z. B. Fehlermeldungen. In der REST-Welt werden die mit einem entsprechenden HTTP-Status-Code zurückgegeben. Ohne HTTP-Kenntnisse kann man also nicht mal eine vernünftige Fehlerbehandlung umsetzen, wenn man RESTful arbeiten will. HTTP ist für REST eine unverzichtbare Grundlage, so wie XML sie für SOAP ist.

AmicaNoctis, könntest du noch ganz kurz einen Satz über die XML-Ressourcendefinition verlieren? Finde wie gesagt nichts dazu, aber kompliziert kann es ja nicht sein. Es ging dabei oben um die automatische, gleichzeitig dynamische Erstellung der passenden Objekte ohne hardcoded PHP-File.

Das ist nichts weiter als eine Konfigurationsdatei in einer eigens definierten XML-Sprache, in der festgelegt ist, welche URL mit welcher Ressourcen-Klasse behandelt werden soll und welche Zusatzinfo eine Instanz dieser Klasse bekommen soll. Hier mal ein Beispiel-Auszug:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE resources
	PUBLIC "-//SednaSoft//DTD ReSTHTTP Resources 1.0//EN"
	"/Projects/Aqua/DTDs/ReSTHTTP/resources.dtd">
<resources>
	<rootResource class="RestrictedReSTResource">
		<resource class="ConnectionResource" pattern="/^connection$/">
			<resource class="ConnectionStatusResource" pattern="/^status$/" />
			<resource class="AuthenticationResource" pattern="/^authentication$/">
				<resource class="ConnectionPasswordResource" pattern="/^password$/" />
				<resource class="ConnectionDetailResource" pattern="/^username$/"
					configMember="username" />
			</resource>
			<resource class="EncodingResource" pattern="/^encoding$/">
				<resource class="ConnectionDetailResource" pattern="/^charset$/"
					configMember="charset" />
				<resource class="ConnectionDetailResource" pattern="/^collation$/"
					configMember="collation" />
			</resource>
			<resource class="HostResource" pattern="/^host$/">
				<resource class="ConnectionDetailResource" pattern="/^name$/"
					configMember="hostName" />
				<resource class="ConnectionDetailResource" pattern="/^port$/"
					configMember="port" />
			</resource>
			<resource class="SchemaResource" pattern="/^schema$/">
				<resource class="ConnectionDetailResource" pattern="/^name$/"
					configMember="schemaName" />
				<resource class="ConnectionDetailResource" pattern="/^prefix$/"
					configMember="prefix" />
			</resource>
		</resource>

		...

	</rootResource>
</resources>

Wenn man also /connection/schema/name anspricht, wird der Request von einer Instanz der Klasse ConnectionDetailResource verarbeitet, die mit einer zusätzlichen Eigenschaft configMember="schemaName" initialisiert wird.

Gruß,

Amica