2012-07-27 16 views
5

Also habe ich in letzter Zeit viel über SOA gelesen und habe versucht, etwas Nützliches zu implementieren. Ich habe mit einem einfachen Blog angefangen und die RESTful API erstellt. So weit, ist es gut. Es funktioniert perfekt. Jedoch fange ich an, meine Haare abzuziehen, wenn ich die Webschnittstelle schreibe, die die RESTful API verbrauchen wird. Ich weiß nicht, ob ich das Richtige tue.Richtiger SOA-Ansatz in PHP-Anwendungen?

Zum Beispiel hat die Weboberfläche ein Admin-Panel. Dieses Admin-Panel führt HTTP-Anfragen über file_get_contents und stream-Optionen an die API aus. Im Moment ist die API localhost, genauso wie die Webschnittstelle, aber der ganze Prozess ist etwas langsamer. Ist das richtig? Ist dies der richtige Weg, eine SOA zu implementieren? Außerdem habe ich mit kleinen Bits doppelten Codes zur Validierung zu tun. Wo sollte ich Daten validieren? In der API oder der Weboberfläche? Was ist der beste Ansatz?

Tipps, Tutorials und vor allem Bücher sind willkommen. Dies wird mithilfe von Silex implementiert, das auf Symfony-Komponenten aufbaut.

+1

Ich denke hier nur laut nach. Das Webinterface wird über localhost gehostet, so dass sich die auf dem Server sitzende API nicht viel ändert, außer dass die Anzahl der Anfragen in der Regel ansteigt und kein Internet zu durchlaufen ist. Ihr Computer wiederholt die Anforderung direkt vor Ihnen, bevor sie die Netzwerkkarte verlässt. Mehr zum Nachdenken. Wenn die API außerhalb Ihrer eigenen Webseiten verwendet wird, würde ich die Datenvalidierung in der API erstellen. Auf diese Weise können Sie Benutzern sowohl die API selbst als auch die Website freigeben. – Kevin

Antwort

1

Genau so mache ich es. Obwohl die Verbindung mit localhost zunächst vielleicht ein Overhead ist, ist dies ein Feature, da Sie bereit sind, Ihre Web-Interface-Anwendung überall bereitzustellen und trotzdem Ihre API zu verwenden, die sich irgendwo befinden könnte. Natürlich würden Sie etwas SSL darüber setzen.

Wie bei der Validierung sollten Sie in der API validieren und HTTP status codes für diese Situationen zurückgeben (z. B. "400 Bad Request" für ungültige Parameter). Auf diese Weise kann jeder andere Client die Antwort von der API interpretieren und behandeln, um anzuzeigen, wie sie gewünscht wird. Im Falle Ihrer Web-Oberfläche, nette kleine Fehlermeldungen basierend auf dem HTTP-Status-Code.

Mit welchen anderen Problemen sind Sie konfrontiert? Was die allgemeine SOA-Architektur angeht, ist this book sehr gut.

+0

Während ich prinzipiell zustimme, wenn Sie Ihre API in der gleichen Box wie Ihr Frontend finden, sollten Sie versuchen, sie in derselben Ausführung aufzurufen, um den Aufwand für Bootstrapping-Ressourcen und Verbindungen zu sparen. Offensichtlich sollte der Wechsel zwischen lokal und remote möglichst nahtlos sein. Mit einem Client-Objekt, um dies zu abstrahieren, könnte dies erreicht werden. –