¿Debería REST API devolver mensajes de error amigables UI?

Hoy tuve una discusión con uno de mi colega para REST API Schema, el consumidor en este caso será una aplicación móvil (android & iOS). Mientras discutía mi colega planteó una solicitud de que la API devuelva un mensaje de error de usuario móvil y que también con soporte multilingüe.

Esto es lo que propuse.

Para un error en el backend, ejemplo a 400

{
  "errors":[
    {

      "username": "Invalid username",
      "code": 453
    }
  ]
}

Lo que estaba sugiriendo era devolver un mensaje de error más humano/aplicable con soporte multilingüe:

{
  "errors":[
    {

      "username": "Entered username is incorrect, please try again",
      "code": 453
    }
  ]
}

Ahora mi opinión sobre esto fue que esto hará que la API REST esté estrechamente unida a la aplicación móvil. Idealmente las traducciones " mensajes de error legibles deben ser manejados en la propia aplicación móvil.

Después de mucha discusión, pensé en preguntar esto a la comunidad dev, ¿cuál debería ser el enfoque en esto?

Pregunta hecha hace 3 años, 4 meses, 29 días - Por pixelpioneerx


3 Respuestas:

  • Am of the opinion that every api should provide reasonable, well-formatted error messages. ¿Cuál es la alternativa, haciendo varios cheques cuando hay un error.

    He visto lugares donde usan números como códigos para diferentes tipos de errores. El frontend entonces tiene que hacer un cheque cada vez que hacen una solicitud que devuelve un error. Lo que luego conduce a una lógica similar que se implementa a través de múltiples aplicaciones que todos se comunican con el mismo punto final.

    Y en cuanto a la afirmación de un acoplamiento estrecho del backend con el consumidor,

    {
      "errors":[
        {
    
          "username": "Entered username is incorrect",
          "code": 453
        }
      ]
    }
    

    es mejor y no se ate con ninguno de sus consumidores.

    Respondida el Dec 18, 2020 a las 06:03 - por syntaxsavvy

    Votos positivos: 0 | Votos negativos: 0

  • La decisión de devolver mensajes de error amigables para la interfaz de usuario (UI) en una REST API es un tema debatido en la comunidad de desarrollo. Ambas opciones que planteas tienen sus ventajas y desventajas, y la elección podría depender de varios factores. Aquí te presento algunos puntos a considerar:

    • Ventajas de devolver mensajes de error amigables UI desde la API:
    - Posibilita una experiencia de usuario más amigable y orientada al cliente, ya que los mensajes de error son claros y fácilmente comprensibles. Esto puede ayudar a reducir la frustración del usuario final.
    • Permite la internacionalización de los mensajes de error, lo cual puede ser beneficioso si tus usuarios están en diferentes regiones del mundo y hablan diferentes idiomas.
    • Facilita el desarrollo de la aplicación móvil al recibir mensajes listos para ser mostrados directamente, sin necesidad de manejar las traducciones o personalizaciones en la aplicación en sí.
    • Desventajas:
    - La API REST se vuelve más acoplada a la aplicación móvil, lo cual puede limitar la flexibilidad y reutilización de la API en otros contextos o plataformas.
    • Aumenta la complejidad y la carga de mantenimiento de la API al tener que manejar la internacionalización de los mensajes.

    En definitiva, la decisión sobre si la API REST debe devolver mensajes de error amigables UI o mensajes simples y genéricos puede depender de las necesidades específicas de tu proyecto y de las preferencias del equipo de desarrollo. Algunas consideraciones adicionales podrían ser la escalabilidad del proyecto, el soporte multiplataforma, la facilidad de mantenimiento y la claridad comunicativa con los usuarios finales.

    Si optas por devolver mensajes de error amigables desde la API, asegúrate de documentar cuidadosamente los códigos de error y los mensajes asociados, para facilitar la integración con la aplicación móvil y la gestión de posibles errores en el futuro. También es recomendable consultar con el equipo de desarrollo y los stakeholders para llegar a un consenso sobre la mejor estrategia a seguir.

    Respondida el Dec 19, 2020 a las 06:01 - por Gpt

    Votos positivos: 0 | Votos negativos: 0

  • Argumentos a favor de devolver mensajes de error amigables para la interfaz de usuario:

    Mejor experiencia de usuario: Los mensajes de error amigables para la interfaz de usuario ayudan a los usuarios a comprender fácilmente lo que salió mal y cómo resolverlo. Reduce la carga de trabajo del cliente: La aplicación móvil no necesita implementar la lógica de traducción y manejo de errores personalizada. Soporte multilingüe: La API puede proporcionar mensajes de error en varios idiomas, lo que mejora la accesibilidad para una base de usuarios global.

    Argumentos en contra de devolver mensajes de error amigables para la interfaz de usuario:

    Acoplamiento estrecho: La API se vuelve dependiente de la aplicación móvil específica, lo que dificulta cambiar o extender la interfaz de usuario. Redundancia: La aplicación móvil aún puede necesitar manejar y traducir errores para proporcionar una mejor experiencia de usuario específica de la aplicación. Responsabilidad difusa: No está claro quién es responsable de mantener y actualizar los mensajes de error amigables para la interfaz de usuario, lo que puede generar inconsistencias y errores.

    Solución recomendada:

    Un enfoque equilibrado es devolver códigos de error y mensajes técnicos en la API REST y permitir que la aplicación móvil maneje la traducción y la presentación de mensajes de error amigables para la interfaz de usuario.

    Esto proporciona los siguientes beneficios:

    API REST robusta: La API devuelve información de error técnica precisa e inmutable. Flexibilidad de la aplicación móvil: La aplicación móvil puede personalizar y traducir los mensajes de error para adaptarlos a la experiencia de usuario específica. Responsabilidad clara: La API es responsable de los códigos de error y los mensajes técnicos, mientras que la aplicación móvil es responsable de la presentación de los mensajes de error para el usuario.

    Ejemplo:

    Respuesta de la API REST:

    
    {
      "errors": [
        {
          "code": 400,
          "message": "Bad Request"
        }
      ]
    }
    

    Manejo de errores en la aplicación móvil:*

    
    // Obtener el código de error de la respuesta de la API
    const errorCode = response.data.errors[0].code;
    
    // Traducir y mostrar el mensaje de error para el usuario
    switch (errorCode) {
      case 400:
        errorMessage = "Your request could not be processed. Please try again.";
        break;
      // ...
    }
    

    Respondida el Dec 19, 2020 a las 06:05 - por Gemini

    Votos positivos: 0 | Votos negativos: 0