Redes, Apps y JSON: JSend

JSON es un formato de intercambio de datos cliente-servidor muy liviano y fácil de utilizar. Junto con XML son los formatos (basados en texto) probablemente más extendidos en la red.

{
    "firstName": "John",
    "lastName": "Smith",
    "age": 25,
    "address": {
        "streetAddress": "21 2nd Street",
        "city": "New York",
        "state": "NY",
        "postalCode": 10021
    },
    "phoneNumbers": [
        {
            "type": "home",
            "number": "212 555-1234"
        },
        {
            "type": "fax",
            "number": "646 555-4567"
        }
    ]
}

Fácil, ¿no?

En el mundo de las aplicaciones móviles JSON es muy importante porque la gran mayoría necesitan conectarse a un servidor para funcionar. AdMob, Yahoo Weather, Google Play Game Services... casi todos los "grandes" usan JSON (y XML), para codificar los datos que intercambian con las aplicaciones.

Y si eres de los "pequeños" ( o de los nuestros ;)), y tienes un servidor que quieres utilizar para desarrollar una App, quizás una base de datos MySql y unos cuantos PHP, un sincero consejo: usa JSON. Las dos grandes plataformas móviles (iOS y Android o Android e iOS), se integran muy bien y también se lleva bien con PHP+MySql. La segunda opción sería XML, pero en mi opinión los móviles hacen mejores migas con JSON.

Y entonces llega la segunda gran pregunta cuando diseñas uno de estos sistemas de intercambio de datos y te das cuenta de que tienes 10 o 20 tipos de mensajes diferentes cliente-servidor y el mismo número de archivos de código para interpretarlos (y por lo tanto un montón de bugs y errores): "Debe existir  algún sistema estándar para estructurar estos mensajes, ¿no?. Así podría reutilizar algo de código y eliminar bugs...".

Pues a falta de una gran respuesta oficial, mi sugerencia es JSend:

{
    status : "success",
    data : {
        "post" : { "id" : 1, "title" : "Título", "body" : "Mensaje" }
     }
}

Los campos principales son:

• status: que indica si la operación ha sido correcta ("success"), ha fallado ("fail") o ha habido un error ("error"). La diferencia entre fallo y error es que el primero se utiliza cuando hay un problema con los datos que se han enviado en la petición o cuando hay un problema en la llamada a la API (p.ej. una petición que requiere estar logueado sin estarlo). 
• data: contiene los datos que se envían en el mensaje en caso de haber sido la operación correcta, o los motivos de fallo. Obligatorio en caso de petición correcta o con fallo.
• message: En caso de haber ocurrido un error (p.ej. en el servidor) indica los motivos del error. Obligatorio en caso de error.
• code: Código descriptivo del error, podéis utilizar los mismos que de HTTP si queréis. Opcional en caso de error.

Ejemplos:

• Petición de datos de un usuario correcta:
  

  {
      "status" : "success",
      "data" : { "post" : { "id" : 1, "username" : "pepe", "name" : "José", "lastname" : "Navarro" }
  }
  

  
  
• Fallo de autenticación:
  

  {
      "status" : "fail",
      "data" : { "title" : "La contraseña no es correcta" }
  }
  

  
  
• Error en el servidor por tiempo de espera superado:
  

  {
      "status" : "error",
      "message" : "Tiempo de espera superado"
      "code" : "508"
  }