PHP url "get"-Parameter-Verarbeitung: Was ist das brauchbarste und wartungsfreundlichste Design, um auf Benutzerfehler zu reagieren?

Question

Stellen Sie sich ein automatisiertes Build-System vor, das die Ergebnisse in einer Datenbank speichert und eine tabellarische Anzeige der Ergebnisse über dynamisches HTML als Antwort auf http GET Anfragen. Da viele verschiedene Nutzer unterschiedliche Teilmengen der Ergebnisse sehen wollen, gibt es Parsing-Skripte in PHP, die jeweils mehrere optionale Filterparameter und -werte akzeptieren. Zum Beispiel (ich lasse den http-Teil weg, damit niemand diese Beispiel-URL tatsächlich anklickt):

display_results.php?componenent_name=meine_comp1&build_type=build_type1&build_owner=fred

Selbst wenn die Liste aller möglichen Parameter und ihrer zulässigen Werte auf einer Hilfeseite aufgeführt ist, hat der Benutzer beim Erstellen einer URL-Anforderung diese Dokumentation möglicherweise nicht zur Hand. Stattdessen ist er darauf angewiesen, sich die gültigen Parameter (einschließlich ihrer Schreibweise) und die zulässigen Werte einzuprägen. Manchmal wird er/sie sich dabei irren.

Frage

Welche der folgenden Optionen ist unter dem Gesichtspunkt der Benutzerfreundlichkeit für den Endbenutzer und der Wartungsfreundlichkeit für den Entwickler am besten geeignet, um auf solche Benutzerfehler zu reagieren?

1. Ungültige Parameter oder Werte ignorieren
2. Ungültige Parameter ignorieren, bei ungültigen Werten nichts zurückgeben
3. Möglichst viele gültige Tabellendaten und eine Fehlermeldung (mit korrekter Verwendung) zurückgeben
4. Nur eine Fehlermeldung zurückgeben (bei korrekter Verwendung)
5. Versuchen Sie es mit der Autokorrektur
6. Sonstiges (erläutern)

Wenn die Datenbank beispielsweise Daten für build_type1 und fred und joe für drei Komponenten namens comp1, comp2 und comp3 enthält und der Benutzer (fälschlicherweise) schreibt:

display_results.php? Name \=comp1,comp2&build_type=build_type1&build_owner= john

1. Würde alle Ergebnisse zurückgeben (weil falscher Parametername "name" ignoriert, ungültiger Wert "john")
2. Würde nichts zurückgeben, da keine Daten für john
3. Würde alle Ergebnisse für build_type1 sowie die Meldungen "no build_owner = john" und "maybe you meant 'component_name'" zurückgeben
4. Würde nur die Meldungen "no build_owner = john" und "maybe you meant 'component_name'" zurückgeben
5. Würde comp1 und comp2 Ergebnisse für build_type1 für joe zurückgeben
6. Sonstiges (Beschreibung)

Ich definiere Benutzerfreundlichkeit als Übereinstimmung mit weit verbreiteten, gut funktionierenden Webanwendungen, die es bereits gibt - wenn die Benutzer mit diesen zufrieden sind, werden sie auch mit der von mir beschriebenen Anwendung zufrieden sein.

Ich stelle diese Frage, weil ich ein Hauptnutzer solcher Skripte bin, eine ganze Reihe von Verbesserungswünschen habe und Unterstützung für weitere Wünsche erhalten möchte.

\=== Über die Schnittstelle - Freiform oder "Builder Page". Ja, ich spreche von Freiform. Es gibt eine "Erstellungsseite" im System, aber (a) sie bietet nie alle Optionen, die alle Benutzer zu wollen scheinen, und (b) ich habe es nicht geschafft, einen Verbesserungsantrag für die "Erstellung von Permalink" durchzusetzen.

\=== Danke für die gewählte Antwort - der Platz im Kommentar reicht nicht aus:

Danke @pygorex1! Sie haben eine Antwort gegeben, die meine Frage in den Kontext eines bekannten Softwarekonstrukts stellt - die API. Und Sie haben ein gutes (wenn auch vielleicht übertriebenes ;-) ) Beispiel für die Auswirkungen einer Verletzung dieser Prinzipien gegeben. Schließlich hat mich noch etwas an den APIs dieser Skripte gestört, und als Sie die "Selbstdokumentation" erwähnten, brachten Sie es für mich auf den Punkt. Was mich gestört hat, war, dass ich, wenn es nur wenig Dokumentation gibt (weil es kostspielig ist, sie auf dem neuesten Stand zu halten) und bei Teilergebnissen, die aufgrund von Benutzerfehlern (meinen!) zurückgegeben werden, nicht lernen alles über das System. "Selbstdokumentation" ist wahrscheinlich die prägnanteste Rechtfertigung für das von Ihnen empfohlene Fehlerbehandlungskonzept. Es ist einfacher, es den Benutzern und Betreuern zu verkaufen!

Answer 1

Das klingt sehr nach einer API. Eines der Markenzeichen einer guten API ist eine klare und konsistente Syntax, damit die Benutzer die vorhersehbar Ergebnisse. Ein Verstoß gegen die Syntax sollte zu einer Fehlermeldung führen.

Die Rückgabe von Teilergebnissen, obwohl die Syntax nicht korrekt ist, ist ein schreckliches Design: Wenn ein Benutzer nicht klar angibt, welche Daten er haben möchte, ist die Wahrscheinlichkeit groß, dass die zurückgegebenen Daten nicht nützlich sind oder verworfen werden. Noch schlimmer ist, dass die Daten als in einem gültigen Kontext stehend behandelt werden können, auch wenn sie es nicht sind.

Ein Beispiel. Das System ist so konzipiert, dass ungültige Parameter ignoriert werden. Ein Client sendet eine comoponent_name Parameter (eine falsche Schreibweise von component_name ), die alle Komponenten des Typs "A" anfordern. Das System liefert daraufhin Komponenten aller Typen ('A', 'B', 'C' ... 'Z') zurück. Der Client behandelt diese Ergebnisse so, als ob sie alle vom Typ "A" wären, und stützt seine internen Berechnungen und seine Geschäftslogik auf diese Ergebnisse. Es kommt zum Chaos, da das Management seine Geschäftsentscheidungen weitgehend auf diese interne Datenanalyse stützt, der Kunde stürzt sich kopfüber in das falsche Marktsegment und geht in Konkurs.

Dies ist zwar ein Weltuntergangsszenario, aber es verdeutlicht einen Punkt: Sie können systemische Fehler abmildern und sogar verhindern, indem Sie Ihre Inputs und Outputs klar definieren.

Überprüfen Sie vor der Rückgabe von Daten die Eingabeparameter. Wenn ein ungültiger Parameter gefunden wird, wird eine Fehlermeldung ausgegeben, die die korrekte Syntax erklärt. Auf diese Weise ist das System selbstdokumentierend und liefert vorhersehbare Ergebnisse.

Answer 2

An meiner Stelle würde ich so viele gültige Informationen wie möglich anzeigen, die ungültigen Parameter in einer Fehlermeldung auflisten und dann eine Liste der gültigen Parameter bereitstellen, die nicht im Abschnitt "gültige Informationen" enthalten waren. Vielleicht ein Formular für jeden gültigen Parameter mit einem zugehörigen Eingabefeld. Dann vielleicht AJAX in der neuen gültigen Informationen, wie es ändert.

Answer 3

Mein erster Gedanke wäre, eine Seite für die URL zu erstellen, anstatt den Benutzern die Möglichkeit zu geben, sich durchzuwühlen. Es sei denn, es gibt einen Grund, der gegen eine Erstellungsseite spricht, dann würde ich dies vorschlagen. Auf diese Weise müssen Sie sich nicht mit dem Problem befassen, die Benutzer über Änderungen zu informieren. Außerdem haben Sie die Möglichkeit, in einigen Fällen nur gültige Optionen anzuzeigen.

Answer 4

Je nach dem gewünschten Verhalten der App bei der Bereitstellung würde ich vorschlagen, entweder eine 400 Bad Request zu senden oder eine Ergebnismenge anzuzeigen, die nur die bereitgestellten Daten verwendet und den Benutzer mit einer Art Flagge darauf hinweist, dass bestimmte einschränkende Parameter ausgelassen wurden.

Sie müssen die Spezifizität der zurückgegebenen Daten bewerten sowie die Frage, ob es zwingend erforderlich ist, dass ein Datensatz immer anstelle eines Fehlers zurückgegeben wird. Wenn es sich um eine Anwendung handelt, die lediglich Daten für den Benutzer sammelt, wie z. B. eine Suche nach einem Katalog, dann ist es sicherlich akzeptabel, die bereitgestellten Parameter zu verwenden und diese lediglich einzuschränken.

Viele große Webanwendungen (z. B. Amazon) stellen jedoch sicher, dass alle Parameter enthalten sind, um den Benutzer zu zwingen, UI-Komponenten innerhalb der Website zu verwenden, anstatt sich mit der URL herumzuschlagen (da diejenigen, die sich damit herumschlagen, im Allgemeinen nicht die besten Absichten haben). Knoten oder der Parameter dh Parameter (dieser bestimmt den Zeichensatz für die Anzeige). Das Zurückschicken von Anfragen mit ausgelassenen oder verfälschten Parametern kann eine gute Möglichkeit sein, die Kontrolle über unerwünschte Eingaben zu behalten.