json - protobuf java
¿Hay una asignación estándar entre JSON y Protocol Buffers? (6)
De un comentario en el anuncio del blog :
Con respecto a JSON: JSON está estructurado de manera similar a los búferes de protocolo, pero el formato binario del búfer de protocolo es aún más pequeño y más rápido de codificar. Sin embargo, JSON es una excelente codificación de texto para búferes de protocolo: es trivial escribir un codificador / decodificador que convierta mensajes de protocolo arbitrarios desde y hacia JSON, utilizando la reflexión de protobuf. Esta es una buena manera de comunicarse con las aplicaciones AJAX, ya que hacer que el usuario descargue un decodificador protobuf completo cuando visite su página puede ser demasiado.
Puede ser trivial preparar un mapeo, pero ¿hay un mapeo "obvio" entre los dos en el que dos equipos de desarrollo independientes se instalarían naturalmente? Si dos productos admitieran datos de PB y pudieran interoperar porque compartían la misma especificación .proto, me pregunto si aún podrían interoperar si introdujeran de forma independiente una reflexión JSON de la misma especificación. Es posible que se deban tomar algunas decisiones arbitrarias, por ejemplo, ¿deberían los valores de enumeración estar representados por una cadena (para que sean legibles por humanos a la JSON típica) o por su valor entero?
Entonces, ¿existe una asignación establecida y alguna implementación de código abierto para generar codificadores / decodificadores JSON a partir de las especificaciones de .proto?
En primer lugar, creo que uno debería razonar con mucho cuidado al hacer un esfuerzo para convertir un conjunto de datos en protobuffs. Aquí mis razones para convertir un conjunto de datos a protobuffs.
- Tipo de seguridad: garantía sobre el formato de los datos considerados.
- Memoria sin comprimir huella de los datos. La razón por la que menciono no comprimido es porque después de la compresión no hay mucha diferencia en el tamaño de JSON comprimido y proto comprimido, pero la compresión tiene un costo asociado. Además, la velocidad de serialización / des-serialización es casi similar, de hecho Jackson Json es más rápido que los protobuffs. Consulte el siguiente enlace para obtener más información http://technicalrex.com/2014/06/23/performance-playground-jackson-vs-protocol-buffers/
- Los protobuffs necesitan ser transferidos a través de la red mucho.
Decir que una vez que convierta su conjunto de datos al formato Jackson JSON de la manera en que se define la definición de ProtoBuff, puede asignarse directamente al formato ProtoBuff utilizando la función Protostuff: JsonIoUtil: mergeFrom. Firma de la función:
public static <T> void mergeFrom(JsonParser parser, T message, Schema<T> schema, boolean numeric)
Referencia a http://technicalrex.com/2014/06/23/performance-playground-jackson-vs-protocol-buffers/
Necesitaba calcular desde GeneratedMessageLite a un objeto JSON, pero no tuve que desmarcarlo. No pude usar la biblioteca protobuf en la respuesta de Pangea porque no funciona con la opción LITE_RUNTIME. Tampoco quise cargar a nuestro gran sistema heredado con la generación de más código compilado para los búferes de protocolo existentes. Para mashalling a JSON, opté por esta solución simple para marshal
final Person gpb = Person.newBuilder().setName("Bill Monroe").build();
final Gson gson = new Gson();
final String jsonString = gson.toJson(gpb);
Por lo que he visto, Protostuff es el proyecto que se utilizará para cualquier trabajo de PB en Java, incluida la serialización como JSON, según la definición del protocolo. Yo no lo he usado, solo he oído cosas buenas.
Puede ser útil http://code.google.com/p/protobuf-java-format/
Sí, desde la versión 3.0.0 de Protocol Buffers (lanzada el 28 de julio de 2016) hay "Una codificación bien definida en JSON como una alternativa a la codificación de proto binario" como se menciona en las notas de la versión
Un pensamiento adicional: si los objetos protobuf tienen captadores / definidores, o campos con el nombre apropiado, uno podría simplemente usar Jackson enlace de datos del procesador Jackson JSON. De forma predeterminada, maneja captadores públicos, cualquier configurador y campo público, pero estos son solo niveles de visibilidad predeterminados y se pueden cambiar. Si es así, Jackson puede serializar / deserializar los POJO generados por protobuf sin problemas.
De hecho, he usado este enfoque con objetos generados por Thrift; lo único que tenía que configurar era deshabilitar la serialización de varios métodos "isXXX ()" que Thrift agrega para verificar si un campo se ha asignado explícitamente o no.