Die ordnungsgemäße Verwendung der HTTP-status-codes in eine "Validierung" server
Unter den Daten meiner Anwendung sendet an einen Dritten SOA-server sind komplexe XML-Dateien. Der server-Besitzer die XML-schemas (.xsd
) und, da der server lehnt ungültige XML-Dateien mit eine sinnlose Nachricht, ich muss überprüfen Sie diese lokal, bevor Sie senden.
Könnte ich mit einem stand-alone-XML-schema-validator aber Sie sind langsam, vor allem wegen der Zeit, die erforderlich ist, um eine Analyse der schema-Dateien. Also schrieb ich mein eigenes schema validator (in Java, falls jene Gegenstände) in form einer HTTP-Server, die caches, die bereits analysiert schemas.
Das problem ist: viele Dinge können schief gehen, im Laufe des Validierungsprozesses. Andere als unerwartete Ausnahmen und erfolgreiche Validierung:
- der server kann nicht finden den schema-Datei angegeben
- die angegebene Datei kann nicht eine gültige schema-Datei
- das XML ist ungültig, gegen die schema-Datei
Da es ein HTTP-Server würde ich zur Verfügung stellen, die Kunden mit aussagekräftigen status-codes. Sollte die server-Antwort mit einem 400 Fehler (Bad request) für alle oben genannten Fälle? Oder Sie haben nichts zu tun mit HTTP und es sollte auch die Antwort auf 200 mit einer Nachricht in den Körper? Jeder andere Vorschlag?
Update: die wichtigste Anwendung ist geschrieben in Ruby, die nicht über eine gute xml-schema-Validierungs-Bibliothek, so dass eine separate Validierungs-server ist nicht over-engineering.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Es ist ein perfekt gültiges denken, um Karten-Fehler-Situationen im überprüfungs-Prozess zu einer sinnvollen HTTP-status-codes.
Ich nehme an, Sie senden Sie die XML-Datei auf Ihrem Validierungs-server als POST-Inhalt mit den URI zu bestimmen, ein bestimmtes schema für die Validierung.
So, hier sind einige Vorschläge für die Fehler-mappings:
Status code 422 ("Unprocessable Entity") klingt nah genug:
"Der 422 (Unprocessable Entity) status-code bedeutet, dass der server versteht den content-type der Anfrage-Entität (also ein 415(Unsupported Media Type) status-code ist ungeeignet), und die syntax der Anfrage-Entität korrekt ist (also ein 400 (Bad Request) status-code ist unpassend) aber nicht in der Lage war zu verarbeiten, die darin enthaltenen Anweisungen. Zum Beispiel, dieser Fehler kann auftreten, wenn ein XML request body enthält wohlgeformte (d.h. syntaktisch korrekt), aber semantisch falsch, XML-Anweisungen."
Amazon kann verwendet werden als ein Modell für die Zuordnung von http-status-codes bis hin zum echten application level Bedingungen:
http://docs.amazonwebservices.com/AWSImportExport/latest/API/index.html?Errors.html (siehe Amazon S3-Status-Codes überschrift)
Sagen, du bist posting XML-Dateien auf eine Ressource, z.B. so:
POST /validator
Content-type: application/xml
Wenn der Antrag Entität ausfällt, zu analysieren, wie die Medien-Typ übertragen wurde, kann es als (ie application/xml), 400 Bad Request ist auf dem richtigen Stand.
Wenn es syntaktisch analysiert, wie die Medien-Typ übertragen wurde, kann es wie, aber es funktioniert nicht validieren gegen einige gewünschte schema, oder sonst hat die Semantik, die es unprocessable durch die Ressource, die es vorgelegt - dann 422 Unprocessable Entity ist der beste status (auch wenn Sie wohl begleiten Sie durch einige Informationen spezifischeren Fehler in der Fehler-Antwort; beachten Sie auch, es ist technisch definiert eine Erweiterung von HTTP, WebDAV, zwar wird ganz allgemein verwendet in HTTP-APIs und vieles mehr geeignet als alle anderen HTTP-Fehler Status, wenn es einen semantischen Fehler mit einem gesendeten entity).
Wenn es vorgelegt wird als media-Typ, was bedeutet, ein bestimmtes schema auf der Oberseite von xml (z.B. als application/xhtml+xml), dann können Sie 400 Bad Request, wenn Sie nicht die Validierung gegen das schema. Aber wenn der media-Typ ist reines XML, dann würde ich argumentieren, dass das schema ist nicht Teil der Medien-Typ, obwohl es ein bisschen eine Grauzone; wenn die xml-Datei legt das schema, könnte man vielleicht interpretieren die Validierung als Teil des syntaktischen Anforderungen für application/xml.
Wenn Sie die übermittlung der XML-Dateien per multipart/form-oder application/x-www-form-urlencoded-Formular, dann müsstest du verwenden, 422 Unprocessable Entity für alle Probleme mit der XML-Datei; 400 würde nur dann sinnvoll sein, wenn es ein syntaktisches problem mit der basic-Formular hochladen.
Vom w3c:
400 = Die Anfrage konnte nicht verstanden werden, indem der server auf Grund von fehlerhaften syntax.
Wäre ich nicht dienen, es sei denn, es war tatsächlich der Fall, dass der server nicht verstehen konnte, die Anfrage. Wenn Sie nur immer ungültiges xml, dienen 200 und erklären, warum Dinge nicht funktionieren.
Grüße
Fake
Ich würde gehen mit
400 Bad request
und eine spezifische Nachricht in den Körper (möglicherweise mit einem sekundären Fehler-code in einen header, wieX-Parse-Error: 10451
für eine leichtere Verarbeitung)Klingt, ist eine nette Idee, aber der HTTP-status-codes nicht wirklich ein "Vorgang fehlgeschlagen" der Fall. Ich würde zurückkehren HTTP 200 mit einem
X-Validation-Result: true/false
- header, der den Körper für einen beliebigen text oder "Vernunft" als notwendig. Speichern Sie die HTTP 4xx, die für die HTTP-level-Fehler, keine Fehler auf Anwendungsebene.Es ist eine Schande und ein Doppel-standard, though. Viele Anwendungen, die HTTP-Authentifizierung verwenden, und Sie sind in der Lage, um zurückzukehren HTTP 401-Nicht Autorisiert oder 403 Forbidden aus der Anwendungsebene. Es wäre zweckmäßig und sinnvoll, um irgendeine Art von Decke, HTTP 4xx-Anfrage Abgelehnt, dass Sie nutzen könnten.