improvisierten Webservice modernisieren?

[danyball]

Hi!

Ich nutze PHP als Webservice zu einer MySQL Datenbank (Frontend ist eine iOS-App). Also 1 PHP-Seite die alle Anfragen handelt - mit riesigem Switch-Statement Läuft, aber nicht gut. Und total unübersichtlich.

Meine Frage an Euch:
Was würdet ihr mir für ein "richtigen" Webservice empfehlen?
(Ich würd PHP gern prozedural weiternutzen - um auch den Aufwand für den Umstieg erstmal kleiner zu halten.)

Danke!!
Daniel

[chorn]

Ich sehe hier keine Voraussetzungen für eine konkrete Empfehlung. Du sagst nur, du hast etwas, das unübersichtlich und langsam ist (warum?), willst aber Techniken um strukturiert zu arbeiten nicht anwenden.

[SebTM]

Hallo,

schau dir mal Tutorials an wie du mit PHP am besten einen Webservice erstellst. Ich denke allerdings wie chorn das du dabei nicht an der Arbeit mit Objekten bzw. OOP vorbeikommen wirst!

[ChristianK]

Am Besten gleich auf REST aufbauen.

[danyball]

Ok danke. Also ich will schon irgendwann zu OOP wechseln. Wollte nur als ersten Schritt eine Technik ohne OOP als Webservice nutzen.

Aber da gibt es wohl nichts :/ Schade.

Anders gefragt: Kann ich mit include oder require_once oder etwas ähnlichen mein riesiges Switch-Statement übersichtlicher gestalten? Oder kostet das alles unnötig Rechenzeit?

[SebTM]

Hallo,

du könntest dir ein eine "if-Condition" schreiben welche prüft ob gewisse "Action-Files" vorhanden sind und dann das entsprechende ausführt.

z.B.

// Check for Action-Parameter
if (!isset($_GET['action']) || empty($_GET['action'])) {
  // Show Service-Manual
  include 'manual.html';
  die();
}

if (file_exists('action_files/' . $_GET['action'] . '.action.php')) {
  // Execute Action-File
  require_once 'action_files/' . $_GET['action'] . '.action.php';
} else {
  // Error-Reponse with Error-Message "invalid Action"
} 

Das ist jetzt nur eben kurz dahingeschustert - aber es wäre eine alternative um für jede Action eine eigene Datei zu haben und so eine gewisse Übersichtlichkeit hinein zu bekommen!

[Tropi]

So wie oben von SebTM beschrieben funktionieren übrigens Local File Inclusions. Das ist nicht unbedingt zu empfehlen.

Klar, kannst du die einzelnen Anweisungen in andere Dateien schubsen, ich frag mich was das an der Übersicht verbessert, außer das du ein zusätzliches File öffnen musst. Zur Performance: Rechenleistung bei Computern ist wesentlich billiger als Denkleistung beim Menschen.

[SebTM]

Schande über mich, Schande über mein Haupt!

Hier die verbesserte Version:

// Check for Action-Parameter
if (!isset($_GET['action']) || empty($_GET['action'])) {
  // Show Service-Manual
  include 'manual.html';
  die();
}

$validActions = array('action1', 'action2', 'test', 'gummibärchen');

if (in_array($_GET['action']m $validActions) && file_exists('action_files/' . $_GET['action'] . '.action.php')) {
  // Execute Action-File
  require_once 'action_files/' . $_GET['action'] . '.action.php';
} else {
  // Error-Reponse with Error-Message "invalid Action"
} 

So dürfte das nicht mehr "ausnutzbar" sein - korrekt?

[mermshaus]

Ja, das mit der Whitelist zulässiger Werte ist jedenfalls eine geeignete Lösung. Das Beispiel selbst könnte und sollte man noch weiter verbessern, aber als grundsätzlicher Hinweis, wie es gemeint ist, wird es wohl reichen.

(Ich halte es zudem auch für komplett legitim, das so „prozedural“/mit Includes zu machen. Es muss nicht grundsätzlich immer OOP sein. )

[Th3Dan]

Ok danke. Also ich will schon irgendwann zu OOP wechseln. Wollte nur als ersten Schritt eine Technik ohne OOP als Webservice nutzen.

Du willst jetzt irgendwas umschreiben und später das ganze noch mal in OOP von vorne? Wie oft willst du deinen Code neu schreiben? Es ist wesentlich vernünftiger und effizienter sich erst mal Gedanken über ein vernünftiges Konzept zu machen und das dann 1x vollständig umzusetzen, anstatt hier und da ein bisschen rumfrickeln um später dann alles neu schreiben zu können. Das ist Zeitverschwendung. Wie viel hängt vom Umfang des Projekes ab, den hier mangels Infos keiner abschätzen kann.

Anders gefragt: Kann ich mit include oder require_once oder etwas ähnlichen mein riesiges Switch-Statement übersichtlicher gestalten? Oder kostet das alles unnötig Rechenzeit?

Grundsätzlich ja, ob das effektiv was bringt sei dahingestellt weil viel zu wenig Infos vorhanden sind und die gegebenen alles andere als konkret ("riesig", "langsam"). Außerdem hängt es davon ab was codeseitig tatsächlich passiert um bewerten zu können, ob etwas tatsächlich langsam ist oder in Anbetracht der Vorgänge welche durchgeführt werden müssen nicht. Das wiederum lässt die Frage aufkommen, wie effizient dein Code ist. Wenn du ne SELECT * Abfrage auf eine Tabelle mit ein etlichen tausend Datensätzen machst aber PHP-Seitig letztendlich nur einen davon weiterverwendest, wird das natürlich recht langsam sein um mal ein Extrembeispiel zu nennen. Das geht noch weiter bis hin zu fehlenden Indizes, wodurch eine Abfrage langsam sein kann. Es gibt wesentlich mehr Faktoren welche die Performance beeinflussen als nicht-modulare Programmierung. Möglicherweise hats auch gar nichts damit zutun und du sitzt einfach nur auf einem overselled Webspace.

Um die Übersichtlichkeit erhöhen kannst du im OOP-Bereich Controller und Actions verwenden. Das bringt dir aber wie gesagt gar nichts, wenn der Flaschenhals z.B. in deinen SQL-Abfragen bzw. deinem Code steckt, was ich für wahrscheinlicher halte. Wenn du konkrete Tipps haben möchtest, musst du ausführliche Infos über dein System und vor allem dessen Code postest, wenigstens mal Auszugsweise. Und bitte mal messen wie lange die Ausführung eines Scriptes dauert, welches du als langsam bezeichnest. Ohne diese Infos gleicht das ganze der berühmten Nadel um Heuhaufen. Alternativ kannst du dich natürlich auch selbst einlesen und rumprobieren (natürlich nicht gerade auf dem Produktivsystem), da lernst du am Meisten, aber das dauert auch am längsten.

[jspit]

Ein Switch-Statement muß nicht zwangsläufig unübersichtlich sein, wenn im case-Zweig nur eine Anweisung steht, wie ein include, ein Funktionsaufruf oder der Aufruf einer Methode.
Die Flexibilität ist noch höher als wenn nur include benutzt werden kann und die einzelnen Zweige können auch mit Kommentaren versehen werden.

(Ich halte es zudem auch für komplett legitim, das so „prozedural“/mit Includes zu machen. Es muss nicht grundsätzlich immer OOP sein. )

Ich stimme dem zu und ergänze, die richtige Mischung aus prozedural und OOP macht PHP so richtig schmackhaft.