API Suche

Hallo zusammen,

ich schaue mir jetzt schon seit Wochen verschiedene API Formen an.

Von XML-RPC über REST bis CORBA an.

Mein Ziel ist es ein Protokoll zu finden mit dem ich recht schnell und einfach in einem Request mehrere Calls machen kann. Sprich mehrere Funktionen von dem Server abfragen.

SOAP hatte ich da eine Weile in der Zerre, das ganze war mir dann doch ein bisschen zu statisch und konnte auch keine multi calls.

REST ist in diesem Sinne ja ehr nicht sehr Praktikabel, wenn man da in den Konventionen bleiben will kann man ja nicht Funktionen wie "authenticate" oder so machen.

In CORBA bin ich noch nicht dahiner gestiegen ;) liegt vlt. auch daran, dass es keine wirklich guten Documentationen füt PHP gibt.

Momentan bin ich bei XML-RPC hängen geblieben, das ist schön dynamisch, kann leider meines Wissens nicht mehrere Calls in einem Request.

Habt ihr evtl. irgendwelche anderen APIs die ihr mit ans Herz legen könntet. Das ganze wäre halt schön, wenn es über HTTP laufen würde.

Dann bedanke ich mich schon mal im Vorraus

CORBA in PHP? Aber sonst gesund? :) Du hast mW so die gängigen RPC-Formen betrachtet, das deckt sich mit meinen bekannten (für/auf Basis von Java gibt es noch ein wohl ganz gutes). Die Frage ist aber elementar: Wieso willst du *unbedingt* mehrere Calls aufeinmal machen? Beispielsweise was? Das ganze kommt ursprünglich aus der Ecke RPC (heißt wirklich so) und Corba, und das sind nun mal entfernte Funktions- bzw. Methodenaufrufe. Prinzipiell lässt der SAOP-Envelope aber durch mehrere Requests/Responses zu? Oder hat der nur eine erlaubte Kardinaltät von 1?

Ja, das mit dem CORBA war mir wie gesagt ein bisschen unklar ;)

Ich habe vor mehr als nur einen "Datensatz" auszulesen, und die Funktionen kann man nicht kapseln, da diese dynamisch modeliert werden können.

Es wäre halt sinnlos in einer Anwendung für jeden Datensatz einen Request zu starten. So ein Request dauert ja schon ein bisschen ;)

Deswegen habe ich gedacht, einen Stack zu nehmen.

Sprich, ich mag auf der ngefragten Seite die News des Users, die Freunde des Users usw... dazu jetzt jedes mal einen Request zu feuern wäre ja voll für die Katz, deswegen wäre es halt schön alle Calls aufzulisen und dann in einem Ritt an den Server zu schicken und eine "große" Antwort zu bekommen.

SOAP ist/war mir einfach zu statisch, klar kann ich auch ohne WSDLs arbeiten, aber dann kann ich gleich einen anderen RPC nehmen.

Deine Anforderungen sind sehr waage. Welches Problem möchtest Du den lösen? Wenn Du mehrere Funktionen auf einen Server aufrufen möchtest, dann bietet es sich doch an, diese Funktionen auf dem Server zu einer Funktion zusammen zu fassen, dieser alle Parameter zu geben und von ihr alle Ergebnisse zurück zu bekommen. Wenn es http sein soll, dann würde ich dafür : http verwenden.

Original von neonlex

Ja, das mit dem CORBA war mir wie gesagt ein bisschen unklar ;)

Ich habe vor mehr als nur einen "Datensatz" auszulesen, und die Funktionen kann man nicht kapseln, da diese dynamisch modeliert werden können.

Es wäre halt sinnlos in einer Anwendung für jeden Datensatz einen Request zu starten. So ein Request dauert ja schon ein bisschen ;)

Deswegen habe ich gedacht, einen Stack zu nehmen.

Sprich, ich mag auf der ngefragten Seite die News des Users, die Freunde des Users usw... dazu jetzt jedes mal einen Request zu feuern wäre ja voll für die Katz, deswegen wäre es halt schön alle Calls aufzulisen und dann in einem Ritt an den Server zu schicken und eine "große" Antwort zu bekommen.

SOAP ist/war mir einfach zu statisch, klar kann ich auch ohne WSDLs arbeiten, aber dann kann ich gleich einen anderen RPC nehmen.

Wo ist das Problem, als Rückgabe mehr als einen Datensatz auszugeben?

Original von Todi42

Deine Anforderungen sind sehr waage. Welches Problem möchtest Du den lösen? Wenn Du mehrere Funktionen auf einen Server aufrufen möchtest, dann bietet es sich doch an, diese Funktionen auf dem Server zu einer Funktion zusammen zu fassen, dieser alle Parameter zu geben und von ihr alle Ergebnisse zurück zu bekommen. Wenn es http sein soll, dann würde ich dafür : http verwenden.

Soweit war mir das vor und nach deiner "Denkpause" auch klar.

Wie gesagt, es ist in meinem Falle nicht möglich eine Funktion zu schreiben, die all diese Funktionen Kapselt.

Deswegen suche ich ja einen RPC dem man nich einen Call sondern einen Call-Stack mitgeben kann.

Original von knalli

Original von neonlex

Ja, das mit dem CORBA war mir wie gesagt ein bisschen unklar ;)

Ich habe vor mehr als nur einen "Datensatz" auszulesen, und die Funktionen kann man nicht kapseln, da diese dynamisch modeliert werden können.

Es wäre halt sinnlos in einer Anwendung für jeden Datensatz einen Request zu starten. So ein Request dauert ja schon ein bisschen ;)

Deswegen habe ich gedacht, einen Stack zu nehmen.

Sprich, ich mag auf der ngefragten Seite die News des Users, die Freunde des Users usw... dazu jetzt jedes mal einen Request zu feuern wäre ja voll für die Katz, deswegen wäre es halt schön alle Calls aufzulisen und dann in einem Ritt an den Server zu schicken und eine "große" Antwort zu bekommen.

SOAP ist/war mir einfach zu statisch, klar kann ich auch ohne WSDLs arbeiten, aber dann kann ich gleich einen anderen RPC nehmen.

Wo ist das Problem, als Rückgabe mehr als einen Datensatz auszugeben?

Die Rückgabe ist ja nicht das Problem.

Ehr die Anfrage

Code:

  
    
  
  
    
  
  ...

Und bei standard XML-RPC geht meines Wissens nicht diese "calls" Verschachtelung.

Wenn du es abstrakt löst, kannst du es auf jeden Fall durch eine Liste (durch Reihenfolge) oder Map (durch Benamung) hinkriegen. Macht das ganze natürlich anfälliger für eine saubere Definition..

Original von neonlex

Wie gesagt, es ist in meinem Falle nicht möglich eine Funktion zu schreiben, die all diese Funktionen Kapselt.

Deswegen suche ich ja einen RPC dem man nich einen Call sondern einen Call-Stack mitgeben kann.

 Du kannst die Funktionsaufrufe nicht auf der Server-Seite zusammen fassen, aber Du hast die Möglichkeit das Protokoll, mit dem die Funktionen aufgerufen werden zu ändern? Klingt "ungewöhnlich".

Ich wette, dass du in diesem Fall bereits mehr Zeit darin investiert hast nach einem passenden Protokoll zu suchen, als die Erstellung eines WrapperObjektes plus Umsetzung mit irgendeienr der genannten Technologien gedauert hätte. Ich kann mir kaum vorstellen, das dies keine Option ist, denn immerhin scheinst du frei in der Protokollwahl zu sein, kannst also die Form deiner übertragenen Datentypen beeinflussen.

Irgendjemand, der dagegen wettet?

So long...

Maxx