Gibt es eine konventionelle Art und Weise der Rückgabe von Fehler-Status von JSON web-services?

Wie schon andere gesagt haben, es gibt keine Universelle Konvention. Der REST der "community" ist immer noch im Prozess der Suche nach ein gewisser Konsens in Fragen wie diese - ein Konsens kann nie gefunden werden. Um nur ein paar Beispiele:

Status code

Standardmäßig ServiceStack.NET ist eine weit verbreitete C# REST-Bibliothek web-service-framework, gibt das Objekt (oder leere Antwort) mit einem status-code, z.B.:

201 Created

Oder:

200 OK

Im Falle eines Fehlers (z.B. eine ArgumentException), kann es tun, z.B.:

400 Bad Request

Und hier ist schon der erste Punkt, wo die Dinge beginnen zu variieren. Einige Menschen wie die 400 status-code für Dinge wie die überprüfung von Fehlern - andere nicht, da 400 wirklich zeigt fehlerhafte syntax in der Anfrage format selbst.

Einige bevorzugen 422 Unprocessable Entity für die Validierung ein Fehler, eine WebDAV-Erweiterung des HTTP-Protokolls, aber immer noch vollkommen akzeptabel und technisch.

Andere denken, Sie sollten, nehmen Sie einfach eine der Fehler-status-codes ungenutzt im HTTP-Protokoll, z.B. 461. Twitter getan haben, mit (unter anderem) 420 Enhance Your Calm benachrichtigt einen client, Sie sind jetzt rate begrenzt - selbst wenn es ein (an der Oberfläche) akzeptabel (und empfohlen) status code 429 Too Many Requests für diesen Zweck bereits.

Etc. Es ist alles eine Frage der Philosophie.

Als für 500 Internal Server Error gilt das gleiche - einige denken, es ist perfekt für alle Arten von Fehlermeldungen, andere denken, dass die 5xx Fehler sollte nur zurückgegeben werden, über Ausnahmen (im eigentlichen Sinne - D. H., außergewöhnliche Fehler). Wenn der Fehler wirklich außergewöhnlich, Sie meistens möchte nicht die chance nutzen und weiterzugeben, die eigentliche exception-info, die vielleicht zu viel verraten über deinen server.

Führt uns zu dem, was (wenn überhaupt etwas) zur Rückkehr in das JSON-Ergebnis? Gleiche Sache...

Antwort

200 OK werden kann, völlig ausreichend für die Beantwortung z.B. eine Anforderung zum löschen einer Ressource, falls kein Fehler aufgetreten ist. In der gleichen Weise, 404 Not Found ist genug, sagen Sie dem client, dass die angeforderte Löschvorgang konnte nicht ausgeführt werden, da das entity zu löschen wurde nicht gefunden. In anderen Fällen benötigen Sie möglicherweise mehr als das.

Einige Leute denken, Sie sollten zählen, wie viel von der erforderlich info wie möglich in die Antwort-Header, oft mit einer leeren Antwort mit " nur Kopfzeilen. Zum Beispiel, auf eine Schöpfung, zurück 201 Created und legen Sie die erstellte entity-ID (als Ressource-URI) in Content-Location. Keine Reaktion erforderlichen Inhalte.

Ich persönlich denke, dass, wenn Sie eine öffentliche API, es ist eine gute Idee, lege die beiden entsprechenden Header und Inhalt, auch wenn der Inhalt etwas redundant. I. e.:

HTTP/1.1 404 Not found
Content-Type: application/json; charset=utf-8
...

{
   'Success': false,
   'Message': 'The user Mr. Gone wasn't found.'
}

(Ich weiß nicht, eigentlich gehören die Success Eigenschaft, aber vielleicht möchte ich, je nach meiner Stimmung bei der Gestaltung der API).

Wenn die Ausführung im DEBUG-Modus, außerdem habe ich eine string-Darstellung der internen service-Aufruf - z.B. 'Request': 'GetUser { id: 5 }', einen Zeitstempel, und der stack-trace. Es ist alles eine Frage der Bequemlichkeit, aber. Es ist leicht genug, um code ein client mit der richtigen benutzerfreundliche Fehlermeldungen einfach auf 404 Not found. Einige andere Fehler (z.B. Validierung) brauchen mehr Kontext, aber. Zum Beispiel:

HTTP/1.1 422 Validation Error
Content-Type: application/json; charset=utf-8
...

{
   'Success': false,
   'Message': 'The request had validation errors.',
   'Errors':
   {
       'UserName': 'The user name must be provided.',
       'Email': 'The email address is already in use.'
   }
}

ServiceStack.NET tut so etwas standardmäßig, aber mit leicht unterschiedlichen Eigenschaften und Inhalte. Microsoft ' s eigene Web-API-framework etwas ähnliches macht.
Die JSend spec verknüpft stellt sich die Frage, ist eine weitere Variante.

Und so weiter.

In kurzen, Nein, es gibt keine Universelle Konvention - noch nicht zumindest. Viele Leute (setzen mehr Gedanken in Sie als ich) arbeiten daran. Aber trotzdem kann es nie sein. Und Ihre Methode ist durchaus akzeptabel.

(Ja, das war sehr langatmig - vor allem, weil ich habe lange gesucht, um für die gleiche Art von "universal-convention" für eine Weile).

Mehr auf status-codes, dies ist ein exzellenter Artikel (zu lang zum zitieren)

Meine 2 Cent:

Ich würde sagen, dass vor allem der statuscode, den Sie zurück schicken, weil die Antwort auf Sie ist die beste Fehler-Anzeige und gibt eine Menge von Optionen in den 4xx-und 5xx-Reihe... (Auch wenn Sie versuchen, HttpGET etwas Kaffee aus einer Kanne, die Sie verwenden können, 418 :D)

Als alles, was nicht 200 ist eine Art von Fehler, und der http-status-codes sind gut dokumentiert in dem Fall sollten Sie verwendet werden, jede weitere Fehlermeldung ist nicht wirklich notwendig (Der Fehler-Beschreibung wird angedeutet durch den statuscode). Browser sind das diejenigen tun, die verlangen, und Sie kümmern sich nicht um die Fehlermeldung, nur den statuscode.

Irgendwelche zusätzlichen Fehlermeldungen könnte auch nur entfernt zu viele Informationen, um mögliche hack-versuche. Ich meine, der Rückkehr einen 403 Forbidden-ist genug Informationen auf Ihrer eigenen, Sie sollte nicht auch wieder ein Meldung "Nicht erlaubt, bitte verwenden Sie '1234' als Passwort statt" 🙂

Ich in der Regel übernehmen die Namen, Struktur und Inhalt des server-side-system als eine Angelegenheit von Praxis.

Diese Praxis wird sichergestellt, dass front-end-Entwickler kommunizieren, um back-end-Entwickler, die mit einem Wortschatz, den Sie verstehen schon, und es nicht einen standard gesetzt/Präzedenzfall, wobei back-end-Entwickler stehen vor der Aufgabe, mit der Umsetzung der neuen Formate als front-end-Entwickler und Designer erfinden neue Konzepte (ein Fehler ist ein Fehler, lass uns nicht Haare Spalten, über den "Typ" und "meta", das sind bloße Attribute eines bestimmten Fehlers.)

So, zum Beispiel, wenn ich zurückkehren werde Fehler-details zu "ein JSON-client" und der service endpoint ist implementiert unter Verwendung von C#, ich möchte wieder eine JSON-Dokument, das wie folgt aussah:

{ 
  "Message": "An error has occurred.", 
  "ExceptionMessage": "Index was outside the bounds of the array.", 
  "ExceptionType": "System.IndexOutOfRangeException", 
  "StackTrace": "   at WebApiTest.TestController.Post(Uri uri) in c:\\Temp\\WebApiTest\\WebApiTest\\TestController.cs:line 18\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClassf.<GetExecutor>b__9(Object instance, Object[] methodParameters)\r\n   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object instance, Object[] arguments)\r\n   at System.Threading.Tasks.TaskHelpers.RunSynchronously[TResult](Func`1 func, CancellationToken cancellationToken)",
}

Nicht zu parrot die akzeptierte Antwort ist, natürlich, ich will nur vermitteln, dass der Wert in der Homogenität ist enorm, vor allem, wenn Sie eine polyglotte (oder "eine völlig neue Programmierer", der ist einfach nicht sicher für die eine oder andere Weise.)

Kann es nicht völlig egal, jetzt, aber in 2, 3 oder 5 Jahre Wartung können Sie beginnen, sorgen, und Sie können sich finden zu müssen "Umschulung" in die lange laufen, wie Sie laufen in andere Entwickler, die sich eine ähnliche Praxis der Konformität und du bist der einzige Mann im team, der noch versucht, erfinden neue Formate (wenn es nicht notwendig ist.)

HINWEIS: klar sein, ich behaupte nicht, Sie serialisieren Ausnahmen an den client. Obwohl, das kann eine perfekt gültige option in vielen Fällen, einschließlich debugging, sichere private clouds, oder, wenn es keine sensiblen Daten/IP, etc.