Este tercer artículo abarca una breve introducción sobre como estructuramos el contenido (cuerpo) de nuestras respuestas HTTP (HTTP Body).
¿Qué es JSON?
JSON (JavaScript Object Notation) es el formato de serialización preferido para el intercambio de información entre las API HTTP más populares de hoy. La especificación para elaborar documentos JSON es extremadamente simple, con unos ejemplos te convertirás en un experto. Esencialmente, un documento JSON contiene objetos de pares clave: valor, donde los valores pueden ser cadenas de texto, números, valores booleanos, nulos o matrices / objetos de más valores.
Esta facilidad de uso y flexibilidad contrasta con otros formatos de datos como XML (muy usados en SOAP), que a menudo requiere una compleja lógica de serialización y una sintaxis detallada para consultar datos. El siguiente es un documento JSON de ejemplo:
{
"nombre": "Gonzalo",
"apellido": "chacaltana",
"resultado": 18,
"report_datetime": "2017-08-18T09: 23: 46 + 00: 00",
"Approved_Cicle": verdadero,
"comentarios": nulo,
"Approved_courses": ["Ruby", "Linux", "MySQL"],
"próximos_cursos": [
{
"nombre": "Vue JS",
"profesor": "Evan Yue",
"twitter": "@youyuxi"
}
{
"nombre": "Python",
"profesor": "Guido van Rossum",
"twitter": "@gvanrossum"
}
{
"nombre": "redis",
"profesor": "salvatore sanfilippo",
"twitter": "@antirez"
}
]
}
Nombre de Atributo
Cuando usas JSON o en realidad cualquier otro formato, una consideración importante es elegir la forma como vas a nombrar a los atributos (nombre de las claves). Puedes elegir entre estas tres opciones:
snake_case: Este formato usa más bytes pero es más fácil de leer.
PascalCase: Este formato no es tan común, obliga a tener más letras mayúsculas.
camelCase: Este formato es legible y usa menos bytes.
Ninguno de los formato es mejor o peor que los demás. Independientemente del formato que elija, es importante ser coherente a lo largo de sus solicitudes y respuestas. Nunca mezcle tipos de formato, ya que será confuso para los desarrolladores recordar qué formato usar en qué situación. Incluso si su servicio es una fachada para varios servicios diferentes y esos tipos de mezcla de servicios, su servicio deberá elegir un único formato y traducir las propiedades. Es común que los proyectos coincidan con el mismo caso de su API externa con variable interna o nombres de propiedad, sin embargo, no hay beneficio para el consumidor en hacerlo.
Valores booleanos
Siempre que utilice propiedades booleanos en su documento JSON, siempre use palabras “positivas”. El cambio entre contrapartes positivas o negativas es confuso y requerirá que el desarrollador revise con frecuencia la documentación. Aquí hay unos ejemplos:
Use enabled en vez de disabled
Use public en vez de private
Por ejemplo, puede indicar que la información que estas devolviendo de un usuario (en formato JSON), esta habilitado (enabled: TRUE) o no esta habilitado (enabled: FALSE).
Cuando se nombran propiedades booleanas, generalmente es excesivo indicar que una propiedad es booleana con el nombre. Como ejemplo, no hay necesidad de llamar a una propiedad is_cool o cool_flag, basta con decir cool:TRUE o cool:FALSE. Si eliges usar un flag, hazlo consistente en toda la API.
Timestamps
Hay algunos estándares diferentes para serializar un timestamp (marca de tiempo). Sin embargo, un formato gobierna sobre todos ellos, y ese formato es ISO 8601. Aquí hay algunos ejemplos de este formato:
"2017-08-15T09:38:46+00:00": Fecha basada en el desplazamiento del UTC.
"2017-08-15T09:39:46Z": Usando “Zulu” UTC time.
"2017-08-15T09:37:46.987Z": Usando precisión de milisegundos.
Este formato de Timestamp siempre se representa como una cadena. Una buena característica es que, suponiendo que cada timestamp se encuentre en la misma zona horaria, cuando se ordenan alfabéticamente, se ordenarán en función de la ocurrencia. También son muy fáciles de leer para los humanos y, sin embargo, son bastantes flexibles.
Una alternativa común es usar el Unix Epoch Time, que es un formato ilegible y ambiguo, es como representar una fecha/hora en formato numérico. Un ejemplo de este formato es 1493268311123, que incluye una precisión de milisegundo, que es diferente de 1493268311, que no lo hace. Es imposible conocer la precisión sin contener información de fuera de banda, como por ejemplo, indicar la precisión con anticipación en la documentación.
Versiones
Al construir y mantener una API HTTP, es común realizar cambios que causarán incompatibilidades en los consumidores. Cuando se realizan estos cambios, es vital que permitamos que los clientes antiguos continúen trabajando con la versión anterior de la API, mientras que admiten una nueva versión en paralelo. Esto permite a los clientes migrar a la nueva versión cuando llegue el momento oportuno.
Aquí hay tres métodos populares para versionar una API HTTP:
URL Segment (como lo usan en LinkedIn, Google+, Twitter): https://api.example.org/v1/*
Accept Header (GitHub): Accept: application/json+v1
Custom Header (Joyent CloudAPI): X-Api-Version: 1
Las nuevas versiones de las API solo se deben realizar cuando las operaciones que normalmente funcionarían con la versión anterior fallarían. Como ejemplo, agregar una nueva propiedad opcional a los recursos o una nueva colección no debería requerir una nueva versión. Cambiar un tipo de valor, agregar un parámetro requerido, eliminar un parámetro o colección, cambiar las opciones predeterminadas de filtrado (por ejemplo, Infinity por defecto a 100 resultados por página) son todos ejemplos de cambios hacia atrás.
Cuando desapruebes una versión anterior de la API, dales a los consumidores suficiente tiempo y atención. Intente notificarles de manera proactiva del cambio e incluso, si es posible, proporcione una guía de migración. Siempre dé una fecha límite si la antigua API se desactivará por completo.
Te esperamos en la tercera parte del articulo en donde hablaremos mas acerca de estos temas que hoy en día son de importancia e interés en el mundo de la tecnología.
