Was sollte ein JSON-Dienst bei einem Fehler / Fehler zurückgeben?

Den HTTP-status-code, den Sie zurückgeben sollte, hängt von der Art des aufgetretenen Fehlers. Wenn eine ID nicht in der Datenbank vorhanden return 404; wenn ein Benutzer nicht über genügend Rechte, um das Ajax-call, return 403; wenn die Datenbank mal aus, bevor Sie in der Lage, finden Sie den Datensatz zurückgeben und 500 (server error).

jQuery automatisch erkennt solche Fehler-codes und führt die callback-Funktion, die Sie definieren, in deinem Ajax-Aufruf. Dokumentation: http://api.jquery.com/jQuery.ajax/

Kurzes Beispiel für eine $.ajax Fehler callback:

$.ajax({
  type: 'POST',
  url: '/some/resource',
  success: function(data, textStatus) {
    //Handle success
  },
  error: function(xhr, textStatus, errorThrown) {
    //Handle error
  }
});

InformationsquelleAutor der Antwort Ron DeVera

Mit HTTP-status-codes wäre eine Erholsamen Weg, es zu tun, aber das würde Ihnen vorschlagen, machen den rest der Schnittstelle RESTful Verwendung von Ressourcen-URIs und so weiter.

In Wahrheit, definieren Sie die Schnittstelle, wie Sie möchten (ein Fehler zurückgegeben Objekt, zum Beispiel, in dem die Eigenschaft mit dem Fehler, und ein Stück HTML-Code, der es erklärt, etc), aber sobald Sie sich entschieden haben, auf etwas, das funktioniert in einem Prototyp, werden rücksichtslos konsequent.

InformationsquelleAutor der Antwort Phil H

Habe ich ein paar Stunden dieses problem zu lösen. Meine Lösung basiert auf der folgende Wünsche/Anforderungen:

• Nicht wiederholende boilerplate-code zur Fehlerbehandlung in allen JSON-controller-Aktionen.
• Erhalten HTTP (Fehler) - status-codes. Warum? Da höhere Ebene betrifft, sollte sich nicht auf unterer Ebene die Umsetzung.
• In der Lage sein, um JSON-Daten, wenn eine Fehlermeldung/exception auf dem server auftreten. Warum? Da möchte ich vielleicht reichen Fehlerinformationen. E. g. Fehlermeldung, domain-spezifische Fehler-status-code -, stack-trace (debug/development environment).
• Benutzerfreundlichkeit der client-Seite - vorzugsweise mit jQuery.

Erstelle ich eine HandleErrorAttribute (siehe code-Kommentare zur Erläuterung der details). Ein paar details wie "aufzuhalten der Benutzung" wurde weggelassen, so könnte der code nicht kompilieren. Ich filter hinzufügen, um die Globale Filter, die während der Initialisierung der Anwendung im Allgemeinen.asax.cs wie diese:

GlobalFilters.Filters.Add(new UnikHandleErrorAttribute());

Attribut:

namespace Foo
{
  using System;
  using System.Diagnostics;
  using System.Linq;
  using System.Net;
  using System.Reflection;
  using System.Web;
  using System.Web.Mvc;

  ///<summary>
  ///Generel error handler attribute for Foo MVC solutions.
  ///It handles uncaught exceptions from controller actions.
  ///It outputs trace information.
  ///If custom errors are enabled then the following is performed:
  ///<ul>
  ///  <li>If the controller action return type is <see cref="JsonResult"/> then a <see cref="JsonResult"/> object with a <c>message</c> property is returned.
  ///      If the exception is of type <see cref="MySpecialExceptionWithUserMessage"/> it's message will be used as the <see cref="JsonResult"/> <c>message</c> property value.
  ///      Otherwise a localized resource text will be used.</li>
  ///</ul>
  ///Otherwise the exception will pass through unhandled.
  ///</summary>
  [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method)]
  public sealed class FooHandleErrorAttribute : HandleErrorAttribute
  {
    private readonly TraceSource _TraceSource;

    ///<summary>
    ///<paramref name="traceSource"/> must not be null.
    ///</summary>
    ///<param name="traceSource"></param>
    public FooHandleErrorAttribute(TraceSource traceSource)
    {
      if (traceSource == null)
        throw new ArgumentNullException(@"traceSource");
      _TraceSource = traceSource;
    }

    public TraceSource TraceSource
    {
      get
      {
        return _TraceSource;
      }
    }

    ///<summary>
    ///Ctor.
    ///</summary>
    public FooHandleErrorAttribute()
    {
      var className = typeof(FooHandleErrorAttribute).FullName ?? typeof(FooHandleErrorAttribute).Name;
      _TraceSource = new TraceSource(className);
    }

    public override void OnException(ExceptionContext filterContext)
    {
      var actionMethodInfo = GetControllerAction(filterContext.Exception);
      //It's probably an error if we cannot find a controller action. But, hey, what should we do about it here?
      if(actionMethodInfo == null) return;

      var controllerName = filterContext.Controller.GetType().FullName; //filterContext.RouteData.Values[@"controller"];
      var actionName = actionMethodInfo.Name; //filterContext.RouteData.Values[@"action"];

      //Log the exception to the trace source
      var traceMessage = string.Format(@"Unhandled exception from {0}.{1} handled in {2}. Exception: {3}", controllerName, actionName, typeof(FooHandleErrorAttribute).FullName, filterContext.Exception);
      _TraceSource.TraceEvent(TraceEventType.Error, TraceEventId.UnhandledException, traceMessage);

      //Don't modify result if custom errors not enabled
      //if (!filterContext.HttpContext.IsCustomErrorEnabled)
      // return;

      //We only handle actions with return type of JsonResult - I don't use AjaxRequestExtensions.IsAjaxRequest() because ajax requests does NOT imply JSON result.
      //(The downside is that you cannot just specify the return type as ActionResult - however I don't consider this a bad thing)
      if (actionMethodInfo.ReturnType != typeof(JsonResult)) return;

      //Handle JsonResult action exception by creating a useful JSON object which can be used client side
      //Only provide error message if we have an MySpecialExceptionWithUserMessage.
      var jsonMessage = FooHandleErrorAttributeResources.Error_Occured;
      if (filterContext.Exception is MySpecialExceptionWithUserMessage) jsonMessage = filterContext.Exception.Message;
      filterContext.Result = new JsonResult
        {
          Data = new
            {
              message = jsonMessage,
              //Only include stacktrace information in development environment
              stacktrace = MyEnvironmentHelper.IsDebugging ? filterContext.Exception.StackTrace : null
            },
          //Allow JSON get requests because we are already using this approach. However, we should consider avoiding this habit.
          JsonRequestBehavior = JsonRequestBehavior.AllowGet
        };

      //Exception is now (being) handled - set the HTTP error status code and prevent caching! Otherwise you'll get an HTTP 200 status code and running the risc of the browser caching the result.
      filterContext.ExceptionHandled = true;
      filterContext.HttpContext.Response.StatusCode = (int)HttpStatusCode.InternalServerError; //Consider using more error status codes depending on the type of exception
      filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);

      //Call the overrided method
      base.OnException(filterContext);
    }

    ///<summary>
    ///Does anybody know a better way to obtain the controller action method info?
    ///See http://stackoverflow.com/questions/2770303/how-to-find-in-which-controller-action-an-error-occurred.
    ///</summary>
    ///<param name="exception"></param>
    ///<returns></returns>
    private static MethodInfo GetControllerAction(Exception exception)
    {
      var stackTrace = new StackTrace(exception);
      var frames = stackTrace.GetFrames();
      if(frames == null) return null;
      var frame = frames.FirstOrDefault(f => typeof(IController).IsAssignableFrom(f.GetMethod().DeclaringType));
      if (frame == null) return null;
      var actionMethod = frame.GetMethod();
      return actionMethod as MethodInfo;
    }
  }
}

Ich entwickelt habe die folgende jQuery-plugin für clientseitige Bedienbarkeit:

(function ($, undefined) {
  "using strict";

  $.FooGetJSON = function (url, data, success, error) {
    ///<summary>
    ///**********************************************************
    ///* UNIK GET JSON JQUERY PLUGIN.                           *
    ///**********************************************************
    ///This plugin is a wrapper for jQuery.getJSON.
    ///The reason is that jQuery.getJSON success handler doesn't provides access to the JSON object returned from the url
    ///when a HTTP status code different from 200 is encountered. However, please note that whether there is JSON
    ///data or not depends on the requested service. if there is no JSON data (i.e. response.responseText cannot be
    ///parsed as JSON) then the data parameter will be undefined.
    ///
    ///This plugin solves this problem by providing a new error handler signature which includes a data parameter.
    ///Usage of the plugin is much equal to using the jQuery.getJSON method. Handlers can be added etc. However,
    ///the only way to obtain an error handler with the signature specified below with a JSON data parameter is
    ///to call the plugin with the error handler parameter directly specified in the call to the plugin.
    ///
    ///success: function(data, textStatus, jqXHR)
    ///error: function(data, jqXHR, textStatus, errorThrown)
    ///
    ///Example usage:
    ///
    ///  $.FooGetJSON('/foo', { id: 42 }, function(data) { alert('Name :' + data.name); }, function(data) { alert('Error: ' + data.message); });
    ///</summary>

    //Call the ordinary jQuery method
    var jqxhr = $.getJSON(url, data, success);

    //Do the error handler wrapping stuff to provide an error handler with a JSON object - if the response contains JSON object data
    if (typeof error !== "undefined") {
      jqxhr.error(function(response, textStatus, errorThrown) {
        try {
          var json = $.parseJSON(response.responseText);
          error(json, response, textStatus, errorThrown);
        } catch(e) {
          error(undefined, response, textStatus, errorThrown);
        }
      });
    }

    //Return the jQueryXmlHttpResponse object
    return jqxhr;
  };
})(jQuery);

Was bekomme ich davon? Das Endergebnis ist, dass

• Keiner meiner controller-Aktionen hat die Anforderungen an HandleErrorAttributes.
• Keiner meiner controller-Aktionen enthält jede sich wiederholende boiler plate code zur Fehlerbehandlung.
• Ich habe einen single-point-of error handling code ermöglicht mir auf einfache Weise ändern Sie die Protokollierung und andere Fehlerbehandlung-related stuff.
• Eine einfache Forderung: Controller-Aktionen JsonResult zurückgeben haben müssen Rückgabetyp JsonResult und nicht einige Basis-Typ, wie ActionResult. Grund: Siehe code-Kommentar in FooHandleErrorAttribute.

Client-Seite Beispiel:

var success = function(data) {
  alert(data.myjsonobject.foo);
};
var onError = function(data) {
  var message = "Error";
  if(typeof data !== "undefined")
    message += ": " + data.message;
  alert(message);
};
$.FooGetJSON(url, params, onSuccess, onError);

Kommentare sind herzlich willkommen! Wahrscheinlich werde ich blog über diese Lösung einige Tag...

InformationsquelleAutor der Antwort Bjarke

Schienen, Gerüste benutzen 422 Unprocessable Entity für diese Art Fehler. Sehen RFC 4918 für weitere Informationen.

InformationsquelleAutor der Antwort ZiggyTheHamster

Wenn der Benutzer ungültige Daten, es sollte auf jeden Fall ein 400 Bad Request (Die request enthält ungültigen syntax oder kann nicht erfüllt werden.)

InformationsquelleAutor der Antwort Daniel Serodio

Für server - /Protokoll-Fehler würde ich versuchen, so zu sein wie die REST/HTTP wie möglich (Vergleichen Sie dies mit der Eingabe in URL in Ihren browser):

• ein nicht vorhandenes Element aufgerufen wird (/Personen/{nicht-vorhandenen-id-hier}). Return 404.
• ein unerwarteter Fehler auf dem server (code-Fehler) aufgetreten. Rendite 500.
• der client-Benutzer ist nicht autorisiert, um die Ressource. Rückkehr 401.

Für domain/business-Logik-spezifische Fehler, die ich würde sagen, das Protokoll ist in der richtigen Weg, und es gibt keine internen server-Fehler, so dass mit einer Fehlermeldung reagieren JSON/XML-Objekt oder was auch immer Sie bevorzugen zur Beschreibung Ihrer Daten mit (Vergleichen Sie dies mit dem Sie das ausfüllen von Formularen auf einer Webseite):

• ein Benutzer ändern will, seinen account-Namen, der Benutzer aber noch nicht überprüfen Sie Ihr Konto, indem Sie auf einen link in einer E-Mail wurde an die Benutzer. Return {"error":"Konto nicht verifiziert"} oder was auch immer.
• ein Benutzer möchte, um ein Buch zu bestellen, aber das Buch verkauft wurde (Zustand geändert, in DB) und kann nicht mehr bestellt. Return {"error":"Buch bereits verkauft"}.

InformationsquelleAutor der Antwort Almer