example - method return json c#

¿Existe una forma convencional de devolver los estados de error de los servicios web de JSON?

Question

Tengo un controlador .NET .ashx, que recibe una publicación de jQuery AJAX, formatea una solicitud de servicio web a un servicio de terceros y consume el resultado. En caso de éxito, crea una instancia de un objeto anónimo con la información relevante y formatea una cadena de respuesta JSON.

En el caso de un error de servicio web, hago lo siguiente:

context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
context.Response.StatusDescription = wsResult.ErrorCode;

Esto hace que tanto el código de estado como la descripción sean fácilmente accesibles a la devolución de llamada de error de jQuery AJAX; Sin embargo, la forma en que he implementado esto es bastante arbitraria.

Después de leer un poco, no puedo encontrar una respuesta concluyente a la siguiente pregunta: ¿Existe una convención (o - incluso - especificación ) universal aceptada para devolver los estados de error a las llamadas AJAX basadas en JSON, lo que permite a cualquier consumidor saberlo? ¿Qué esperar, o esto es tan arbitrario como un tipo de retorno para cualquier otra llamada de función?

Entonces, ¿es esta una forma perfectamente aceptable de devolver un estado de error a la persona que llama AJAX, o existe una forma "adecuada" de formatear una respuesta de error JSON?

Answer 1

Como han dicho otros, no hay una convención universal. La "comunidad" de REST todavía está en proceso de encontrar algún consenso en asuntos como estos; tal vez nunca se pueda encontrar un consenso. Solo para dar algunos ejemplos:

Código de estado

De forma predeterminada, ServiceStack.NET, un marco de servicios web de biblioteca de C # REST ampliamente utilizado, devuelve el objeto (o respuesta vacía) con un código de estado, por ejemplo:

201 Created

O:

200 OK

En el caso de un error de validación (por ejemplo, una ArgumentException ), puede hacer por ejemplo:

400 Bad Request

Y aquí está el primer punto donde las cosas comienzan a variar. A algunas personas les gusta el código de estado 400 para cosas como errores de validación, otras no, ya que 400 realmente indica una sintaxis con formato incorrecto en el formato de solicitud .

Algunos prefieren la 422 Unprocessable Entity para errores de validación, una extensión WebDAV al protocolo HTTP, pero aún así técnicamente perfectamente aceptable.

Otros piensan que simplemente debe tomar uno de los códigos de estado de error no utilizados en el protocolo HTTP, por ejemplo, 461 . Twitter ha hecho eso con (entre otros) 420 Enhance Your Calm para notificar a un cliente que ahora está teniendo un límite de velocidad, incluso si hay un código de estado aceptable (y recomendado) (en la superficie) 429 Too Many Requests para ese fin ya .

Etc. Todo es cuestión de filosofía.

En cuanto a 500 Internal Server Error , se aplica lo mismo: algunos piensan que está perfectamente bien para todo tipo de respuestas de error, otros piensan que los errores 5xx solo deben devolverse en excepciones (en el sentido real, es decir, errores excepcionales). Si el error es realmente excepcional, en su mayoría no querrá arriesgarse y pasar cualquier información de excepción real, que puede revelar demasiado acerca de su servidor.

¿Llevándonos a qué (si es que hay) devolver en el resultado de JSON? La misma cosa...

Respuesta

200 OK puede ser suficiente para responder, por ejemplo, a una solicitud para eliminar un recurso, si no se produce un error. De la misma manera, 404 Not Found es suficiente para decirle al cliente que no se pudo realizar la eliminación solicitada porque no se encontró la entidad a eliminar. En otros casos puede requerir más que eso.

Algunas personas piensan que debería incluir la mayor cantidad de información necesaria en los encabezados de respuesta, a menudo con una respuesta vacía con solo encabezados. Por ejemplo, en una creación, devuelva 201 Created y coloque la ID de la entidad creada (como un URI de recurso) en Content-Location . No se necesita contenido de respuesta.

Personalmente, creo que si está creando una API pública, es una buena idea devolver tanto los encabezados como el contenido, incluso si el contenido es algo redundante. Es decir:

HTTP/1.1 404 Not found
Content-Type: application/json; charset=utf-8
...
{
''Success'': false,
''Message'': ''The user Mr. Gone wasn''t found.''
}

(En realidad no incluyo la propiedad Success , pero es posible que quiera hacerlo, dependiendo de mi estado de ánimo al diseñar la API).

Cuando se ejecuta en modo DEBUG, también incluyo una representación de cadena de la llamada de servicio interna, por ejemplo, ''Request'': ''GetUser { id: 5 }'' , una marca de tiempo y el seguimiento de la pila. Sin embargo, todo es cuestión de conveniencia. Es bastante fácil codificar a un cliente con mensajes de error apropiados y fáciles de usar, simplemente basados ​​en 404 Not found . Sin embargo, algunos otros errores (por ejemplo, la validación) pueden necesitar más contexto. Por ejemplo:

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 hace algo así de forma predeterminada , pero con propiedades y contenido ligeramente diferentes. El propio marco de API web de Microsoft hace algo similar . La especificación JSend vinculada en la pregunta relacionada es otra variación.

Y así.

En resumen, no, no hay ninguna convención universal, al menos, todavía no. Mucha gente (pensando más en eso que yo) está trabajando en ello. Pero aún así, puede que nunca haya. Y tu método es perfectamente aceptable.

(Sí, esto fue muy largo, principalmente porque he estado buscando el mismo tipo de "convención universal" por un tiempo).

Para más información sobre los códigos de estado, este es un excelente artículo (demasiado largo para citarlo aquí)

Answer 2

Generalmente adopto los nombres, la estructura y el contenido del sistema del lado del servidor como una cuestión de práctica.

Esta práctica garantiza que los desarrolladores de aplicaciones para el usuario se comuniquen con los desarrolladores de servicios de fondo utilizando un vocabulario que ya comprenden, y no establece un estándar / precedente por el cual los desarrolladores de servicios de fondo tienen la tarea de implementar nuevos formatos a medida que los desarrolladores y diseñadores de aplicaciones de usuario inventar. conceptos nuevos (un error es un error, no dividamos los pelos sobre "tipo" y "meta", que son meros atributos de cualquier error dado).

Entonces, por ejemplo, si estoy devolviendo los detalles del error a "un cliente JSON" y el punto final del servicio se implementa usando C #, me gustaría devolver un documento JSON que se parece a esto:

{
"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)",
}

Por supuesto, para no repetir la respuesta aceptada, solo quiero transmitir que el valor de la uniformidad es enorme, especialmente si eres un políglota (o "un programador completamente nuevo" que simplemente no está seguro de una manera u otra).

Puede que no le importe a usted ahora, pero en 2, 3 o 5 años de mantenimiento puede comenzar a preocuparse, y puede tener que "volver a entrenar" a la larga al encontrarse con otros desarrolladores que adoptan una práctica similar de conformidad y eres el único jugador del equipo que aún intenta inventar nuevos formatos (cuando no es necesario).

NOTA : Para que quede claro, no estoy sugiriendo que serialice las excepciones al cliente. Aunque, esa puede ser una opción perfectamente válida en muchos escenarios, incluyendo depuración, nubes privadas seguras, o cuando no hay datos confidenciales / IP, etc.

Answer 3

Mis 2 centavos:

Yo diría que, ante todo, el código de estado que envías como respuesta es el mejor indicador de error y ofrece muchas opciones en el rango 4xx y 5xx ... (Incluso cuando intentas HttpGET un poco de café de una tetera, puedes usar 418: D)

Como todo lo que no es 200 es algún tipo de error, y los códigos de estado http están bien documentados, en cuyo caso deberían utilizarse, no es necesario ningún otro mensaje de error (la descripción del error está implícita en el código de estado). Los navegadores son los que hacen la solicitud y no les importa el mensaje de error, solo el código de estado.

Cualquier mensaje de error adicional podría también alejar demasiada información para posibles intentos de pirateo. Quiero decir, devolver un 403 Forbidden es suficiente información por sí solo, no debería devolver un mensaje que diga "No permitido, use ''1234'' como contraseña" :)

Answer 4

No, no hay ningún estándar importante por ahí, aunque esto podría ser bueno. Puede ser útil si se está haciendo un estándar para incluir el success y los details , pero depende de cómo lo esté utilizando exactamente. Creo que la gran ventaja es cuando implementas un estándar al menos en todo tu propio código para mantener la coherencia, por ejemplo, http://ricardocovo.com/2012/03/08/asp-net-mvc-using-json-standard-responses-for-your-ajax-calls/

Su respuesta es completamente aceptable si se ajusta a sus necesidades. Si estuviera trabajando con una API, vería esa respuesta de error como "estándar", que contiene un código de respuesta y una descripción, aunque me gustaría un success booleano por su facilidad de uso.

Answer 5

La guía de estilo de Google JSON usa data x o objetos de error ...

Para mantener una interfaz coherente en todas las API, los objetos JSON deben seguir la estructura que se describe a continuación. Esta estructura se aplica tanto a las solicitudes como a las respuestas realizadas con JSON.
. . .
El objeto JSON tiene algunas propiedades de nivel superior, seguidas de un objeto de data o un objeto de error , pero no de ambos.

Un example ...

{
"apiVersion": "2.0",
"error": {
"code": 404,
"message": "File Not Found",
"errors": [{
"domain": "Calendar",
"reason": "ResourceNotFoundException",
"message": "File Not Found
}]
}
}