php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Scripts > BRAINSTORMING PHP/SQL/HTML/JS/CSS
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


BRAINSTORMING PHP/SQL/HTML/JS/CSS Ihr habt eine Idee, aber keinen genauen Ansatz? Diskutiert mit anderen Usern des Forums über eure Gedankengänge um evtl. hilfreiche Ideen zu bekommen!
Normale Fragen bitte weiterhin in die entsprechenden Foren!

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 22-02-2010, 22:08
INC.
 Registrierter Benutzer
Links : Onlinestatus : INC. ist offline
Registriert seit: Nov 2005
Beiträge: 106
INC. ist zur Zeit noch ein unbeschriebenes Blatt
Standard PHP Backend allgemein gestalten für AJAX/Flash/Silverlight etc.

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.

Geändert von INC. (22-02-2010 um 22:11 Uhr)
Mit Zitat antworten
  #2 (permalink)  
Alt 22-02-2010, 22:18
Benutzerbild von onemorenerd onemorenerd
  Moderator
Links : Onlinestatus : onemorenerd ist offline
Registriert seit: Mar 2005
Ort: Berlin
Beiträge: 9.471
onemorenerd wird schon bald berühmt werdenonemorenerd wird schon bald berühmt werden
Standard

Zitat:
Zitat von INC. Beitrag anzeigen
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?
Mit Zitat antworten
  #3 (permalink)  
Alt 22-02-2010, 22:19
Hopka
 PHP Expert
Links : Onlinestatus : Hopka ist offline
Registriert seit: May 2003
Ort: Köln
Beiträge: 2.172
Hopka ist zur Zeit noch ein unbeschriebenes Blatt
Hopka eine Nachricht über ICQ schicken
Standard

Der Unterschied zwischen dem hier:

Zitat:
Zitat von INC. Beitrag anzeigen
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).
__________________
hopka.net!
Mit Zitat antworten
  #4 (permalink)  
Alt 22-02-2010, 22:58
INC.
 Registrierter Benutzer
Links : Onlinestatus : INC. ist offline
Registriert seit: Nov 2005
Beiträge: 106
INC. ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Danke schonmal euch beiden.

Zitat:
Zitat von onemorenerd Beitrag anzeigen
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?

Zitat:
Zitat von Hopka Beitrag anzeigen
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,


Zitat:
Zitat von Hopka Beitrag anzeigen
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:

PHP-Code:
$value = array(12'foo');
$output $json->encode($value);
print(
$output); 
Und den Input bekomt man so

PHP-Code:
$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!

Geändert von INC. (22-02-2010 um 23:00 Uhr)
Mit Zitat antworten
  #5 (permalink)  
Alt 22-02-2010, 23:16
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Zitat:
Zitat von INC. Beitrag anzeigen
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
__________________
Hast du die Grundlagen zur Fehlersuche gelesen? Hast du Code-Tags benutzt?
Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
Super, danke!
Mit Zitat antworten
  #6 (permalink)  
Alt 22-02-2010, 23:17
Hopka
 PHP Expert
Links : Onlinestatus : Hopka ist offline
Registriert seit: May 2003
Ort: Köln
Beiträge: 2.172
Hopka ist zur Zeit noch ein unbeschriebenes Blatt
Hopka eine Nachricht über ICQ schicken
Standard

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.
__________________
hopka.net!
Mit Zitat antworten
  #7 (permalink)  
Alt 23-02-2010, 00:01
INC.
 Registrierter Benutzer
Links : Onlinestatus : INC. ist offline
Registriert seit: Nov 2005
Beiträge: 106
INC. ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Zitat von AmicaNoctis Beitrag anzeigen
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.

Zitat:
Zitat von Hopka Beitrag anzeigen
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
Mit Zitat antworten
  #8 (permalink)  
Alt 23-02-2010, 00:11
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

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.
__________________
Hast du die Grundlagen zur Fehlersuche gelesen? Hast du Code-Tags benutzt?
Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
Super, danke!

Geändert von AmicaNoctis (23-02-2010 um 00:13 Uhr)
Mit Zitat antworten
  #9 (permalink)  
Alt 23-02-2010, 00:45
INC.
 Registrierter Benutzer
Links : Onlinestatus : INC. ist offline
Registriert seit: Nov 2005
Beiträge: 106
INC. ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Zitat von AmicaNoctis Beitrag anzeigen
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.

Zitat:
Zitat von AmicaNoctis Beitrag anzeigen
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.

Zitat:
Zitat von AmicaNoctis Beitrag anzeigen
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.
Mit Zitat antworten
  #10 (permalink)  
Alt 23-02-2010, 01:08
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

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
__________________
Hast du die Grundlagen zur Fehlersuche gelesen? Hast du Code-Tags benutzt?
Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
Super, danke!
Mit Zitat antworten
  #11 (permalink)  
Alt 23-02-2010, 01:17
wahsaga
  Moderator
Links : Onlinestatus : wahsaga ist offline
Registriert seit: Sep 2001
Beiträge: 25.236
wahsaga befindet sich auf einem aufstrebenden Ast
Standard

Zur Ergänzung, der Vollständigkeit halber:
Zitat:
Zitat von AmicaNoctis Beitrag anzeigen
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).
__________________
I don't believe in rebirth. Actually, I never did in my whole lives.
Mit Zitat antworten
  #12 (permalink)  
Alt 23-02-2010, 01:23
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Zitat:
Zitat von wahsaga Beitrag anzeigen
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.
__________________
Hast du die Grundlagen zur Fehlersuche gelesen? Hast du Code-Tags benutzt?
Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
Super, danke!
Mit Zitat antworten
  #13 (permalink)  
Alt 23-02-2010, 23:19
PHP-Desaster
 PHP Expert
Links : Onlinestatus : PHP-Desaster ist offline
Registriert seit: Mar 2006
Beiträge: 3.105
PHP-Desaster befindet sich auf einem aufstrebenden Ast
Standard

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.
Mit Zitat antworten
  #14 (permalink)  
Alt 01-03-2010, 17:38
INC.
 Registrierter Benutzer
Links : Onlinestatus : INC. ist offline
Registriert seit: Nov 2005
Beiträge: 106
INC. ist zur Zeit noch ein unbeschriebenes Blatt
Standard

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

Zitat:
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.

Geändert von INC. (01-03-2010 um 17:40 Uhr)
Mit Zitat antworten
  #15 (permalink)  
Alt 01-03-2010, 19:09
AmicaNoctis
  Moderatorin
Links : Onlinestatus : AmicaNoctis ist offline
Registriert seit: Jul 2009
Beiträge: 5.709
Blog-Einträge: 9
AmicaNoctis sorgt für eine eindrucksvolle AtmosphäreAmicaNoctis sorgt für eine eindrucksvolle Atmosphäre
Standard

Zitat:
Zitat von INC. Beitrag anzeigen
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.

Zitat:
Zitat von INC. Beitrag anzeigen
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.

Zitat:
Zitat von INC. Beitrag anzeigen
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:

HTML-Code:
<?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
__________________
Hast du die Grundlagen zur Fehlersuche gelesen? Hast du Code-Tags benutzt?
Hast du als URL oder Domain-Beispiele example.com, example.net oder example.org benutzt?
Super, danke!

Geändert von AmicaNoctis (01-03-2010 um 19:14 Uhr)
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Backend Bereich paulll Projekthilfe 1 06-11-2009 10:53
[SQL allgemein] SELECT ohne spezifische Spaltenangabe kürzer gestalten ApoY2k SQL / Datenbanken 4 21-02-2009 17:11
[Festanstellung] Vollzeitstelle (w/m) im Backend Hitflip Archiv / Trash 2 25-07-2008 11:21
Ajax/Flash Entwickler Phily21 Jobgesuche 0 05-02-2007 22:03
Patent auf Webapplikationen mit AJAX, Java, Flash & Co. Berni News / Kostenloses 8 21-03-2006 00:02

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 03:56 Uhr.