javascript - ejemplo - document.title jquery
¿Hay algún método conocido para secar JSON? (5)
Considere esta respuesta JSON:
[{
Name: ''Saeed'',
Age: 31
}, {
Name: ''Maysam'',
Age: 32
}, {
Name: ''Mehdi'',
Age: 27
}]
Esto funciona bien para una pequeña cantidad de datos, pero cuando quiere servir cantidades más grandes de datos (por ejemplo, muchos miles de registros), parece lógico evitar esas repeticiones de nombres de propiedades en la respuesta JSON de alguna manera.
Busqué en Google el concepto (DRYing JSON) y, para mi sorpresa, no encontré ningún resultado relevante. Una forma, por supuesto, es comprimir JSON utilizando un algoritmo simple hecho en casa y descomprimirlo en el lado del cliente antes de consumirlo:
[[''Name'', ''Age''],
[''Saeed'', 31],
[''Maysam'', 32],
[''Mehdi'', 27]]
Sin embargo, una mejor práctica sería mejor que cada desarrollador tratando de reinventar la rueda. ¿Han visto una solución ampliamente aceptada para esto?
¿Utiliza gzip -compresión que generalmente se integra fácilmente en la mayoría de los servidores y clientes web?
Todavía tomará algo de tiempo (extra) y memoria para generar y analizar el JSON en cada extremo, pero no tomará mucho tiempo para enviar a través de la red, y tomará un esfuerzo mínimo de implementación en su nombre.
Podría valer la pena un disparo incluso si comprime previamente los datos de origen de alguna manera.
En primer lugar, JSON no pretende ser la forma más compacta de representar datos. Está destinado a ser analizable directamente en una estructura de datos javascript diseñada para consumo inmediato sin análisis adicional. Si desea optimizar el tamaño, entonces probablemente no desee que JSON se describa a sí mismo y necesita permitir que su código realice una serie de suposiciones acerca de cómo manejar los datos y ponerlos en uso y hacer un análisis manual en la recepción. fin. Esas suposiciones y el trabajo de codificación adicional pueden ahorrarle espacio.
Si el código ya conoce los nombres de las propiedades y el formato de la respuesta del servidor, simplemente podría devolver los datos como una matriz de valores alternativos:
[''Saeed'', 31, ''Maysam'', 32, ''Mehdi'', 27]
o si es seguro asumir que los nombres no incluyen comas, incluso podría devolver una cadena delimitada por comas que podría dividir en partes y pegar en sus propias estructuras de datos:
"Saeed, 31, Maysam, 32, Mehdi, 27"
o si aún desea que sea JSON válido, puede colocar esa cadena en una matriz como esta, que es solo un poco mejor que mi primera versión, donde los elementos en sí son elementos de matriz:
["Saeed, 31, Maysam, 32, Mehdi, 27"]
Estas suposiciones y la compacidad ponen más responsabilidad en el análisis de los datos en su propio javascript, pero es la eliminación de la naturaleza autodescriptiva del JSON completo con el que comenzó lo que conduce a su naturaleza más compacta.
En realidad, no es un problema para JSON que a menudo tenga una cadena masiva o una duplicación de "propiedades" (ni tampoco para XML).
Esto es exactamente lo que el componente de eliminación de cadena duplicada de las direcciones del algoritmo DEFLATE (usado por GZip).
Si bien la mayoría de los clientes del navegador pueden aceptar respuestas comprimidas con GZip, el tráfico al servidor no lo será.
¿ https://github.com/WebReflection/json.hpack/wiki justifica el uso de "compresión JSON" (es decir, https://github.com/WebReflection/json.hpack/wiki o algún otro esquema)?
Es poco probable que sea mucho más rápido que implementar la compresión GZip en Javascript (lo cual no es imposible; en una máquina razonablemente rápida puede comprimir 100 KB en 250 ms).
Es bastante difícil procesar de forma segura la entrada JSON no confiable. Debe usar el análisis basado en la transmisión y decidir sobre un umbral de máxima complejidad, de lo contrario, su servidor podría sorprenderlo. Ver, por ejemplo, Armin Ronacher''s Start Writing More Classes :
Si su pequeño servidor web está recibiendo 10000 solicitudes por segundo a través de gevent pero está usando json.loads, entonces probablemente pueda hacer que el rastreo se detenga enviándole 16 MB de JSON bien diseñado y anidado que consumen toda su CPU.
Es posible que pueda usar un formato CSV en lugar de JSON, ya que solo especificaría los nombres de las propiedades una vez. Sin embargo, esto requeriría una estructura rígida como en su ejemplo.
JSON no es realmente el tipo de cosa que se presta a DRY, ya que está bastante bien empaquetado considerando lo que puedes hacer con él. Personalmente, he usado arreglos simples para datos JSON que se almacenan en un archivo para su uso posterior, pero para solicitudes simples de AJAX simplemente lo dejo como está.
DRY generalmente se refiere a lo que usted mismo escribe, por lo que si su objeto se genera dinámicamente, no debería preocuparse por ello de todos modos.
Una solución es conocida como algoritmo hpack.