PHP und benutzerdefinierte HTTP-Header, schlechte Praxis?

Question

Ich habe eine benutzerdefinierte Implementierung einer RESTful API für eine PHP-Anwendung, die JSON-Daten zurückgibt, und um den Status der Operation zu kommunizieren, dh ob es Fehler in der Anfrage gab, stelle ich einen benutzerdefinierten HTTP-Header mit ein (sehr kleines) json-Objekt als String. Dies funktioniert gut, da ich Antworten senden und sie leicht Client-Seite abrufen kann, ohne mit den tatsächlichen gesendeten Daten zu verwirren.

Die Frage ist, gibt es irgendwelche Nachteile, die ich nicht mit dieser Methode realisiert haben könnte? Es scheint nicht sehr üblich für Anwendungen zu sein, benutzerdefinierte HTTP-Header zu setzen, also frage ich mich, ob es eine schlechte Übung oder ein schlechter "Geschmack" ist.

Answer 1

Dies ist eine interessante Frage. Es sollte keinen Grund dafür geben, dass es ein Problem ist, aber Sie sollten ein paar Dinge berücksichtigen:

1. Die Header müssen für Ihre Anwendung eindeutig sein. Nicht nur jetzt, sondern für immer. Sie sollten sicherstellen, dass Sie ihnen vorangestellt sind, z. X-MyApplication-Foo: Bar. Wenn Sie dies nicht tun, können Sie in Zukunft Konflikte verursachen.
   
   
2. Firewalls sind manchmal (selten) ein wenig übereifrig mit dem Filtern unbekannter HTTP-Header. Dies sollte kein Problem sein, aber es ist etwas zu beachten.
   
   
3. Ältere Browser haben kleinere Einschränkungen für Header-Feldgrößen als moderne Browser, daher müssen Sie so viele testen, wie Sie bekommen können.
   
   

Gibt es Grund, warum Sie nicht den Standard-HTTP-Fehlercodes verwenden können? Ich verstehe, dass Sie möglicherweise Stack-Traces oder andere nützliche Debugging-Informationen bereitstellen möchten, aber würden Sie im Falle eines Fehlers nicht einfach ein JSON-Blob zurückgeben, das die Fehlerinformationen enthält, anstatt die normalen "Ergebnis" -JSON-Daten? Sie können den Unterschied anhand des HTTP-Fehlercodes leicht erkennen und die beiden Fälle unterschiedlich behandeln.

Der Grund, warum ich von Ihrem vorgeschlagenen Ansatz betroffen bin, ist, dass Header verwendet werden, um Browser Verhalten zu ändern oder zu verursachen - sie sind nicht als Datenspeichermechanismus gedacht.

Pseudo-Code-Beispiel:

switch(httpResponseCode) 
{ 
    case 200: 
     parseResult(json); 
     break; 
    case 403: 
     parseForbidden(json); 
     break; 
    case 500: 
     parseServerError(json); 
     break; 
    default: 
     // bad response code, handle appropriately 
}