2010-03-30 12 views
23

Da un commento sul announcement blog post:Esiste una mappatura standard tra JSON e Protocol Buffers?

Per quanto riguarda JSON: JSON è strutturato in modo simile a protocollo buffer, ma buffer di protocollo formato binario è ancora più piccolo e più veloce per codificare. JSON fa un grande codifica di testo per buffer di protocollo, anche se - è banale scrivere un codificatore/decodificatore che converte il protocollo arbitrario messaggi dalla JSON, utilizzando protobuf riflessione. Questo è un buon modo per comunicare con le app AJAX, dato che l'utente scarica un completo decodificatore quando visita la tua pagina potrebbe essere troppo.

Può essere banale per cucinare una mappatura, ma c'è una sola mappatura "ovvio" tra i due che qualsiasi due squadre dev separati sarebbe naturalmente stabilirsi? Se due prodotti supportavano i dati PB e potevano interagire perché condividevano la stessa specifica .proto, mi chiedo se sarebbero ancora in grado di interoperare se introdurranno in modo indipendente una riflessione JSON della stessa specifica. Potrebbero esserci alcune decisioni arbitrarie da prendere, ad es. i valori enum dovrebbero essere rappresentati da una stringa (per essere leggibili dall'uomo al tipico JSON) o dal loro valore intero?

Quindi esiste una mappatura stabilita e qualsiasi implementazione open source per la generazione di codificatori/decodificatori JSON dalle specifiche di .proto?

risposta

6

Da quello che ho visto, Protostuff è il progetto da utilizzare per qualsiasi lavoro PB su Java, tra cui la serializzazione come JSON, sulla base di definizione di protocollo. Non l'ho usato da solo, ho solo sentito cose buone.

+0

Nessun nuovo [CHANGELOG] (https://github.com/protostuff/protostuff/blob/master/CHANGELOG.md) voci dal 2015. Nessuna modifica per 5 mesi. Un progetto moribondo? – Raedwald

1

Un ulteriore pensiero: se gli oggetti protobuf hanno getter/setter o campi con nome appropriato, è possibile utilizzare semplicemente l'associazione dati del processore JSON Jackson. Per impostazione predefinita gestisce getter pubblici, setter e campi pubblici, ma questi sono solo livelli di visibilità predefiniti e possono essere modificati. In tal caso, Jackson può serializzare/deserializzare POJO generati da protobuf senza problemi.

In realtà ho usato questo approccio con oggetti generati dalla deriva; l'unica cosa che dovevo configurare era disabilitare la serializzazione di vari metodi "isXXX()" che Thrift aggiunge per verificare se un campo è stato assegnato o meno esplicitamente.

+2

Non è così semplice: gli oggetti Java generati dalle specifiche di protobuf sono di sola lettura e usano una classe Builder per creare nuove istanze. – djjeck

+0

Questo potrebbe essere cambiato, ma nel passato penso che le proprietà non siano definitive e possano quindi essere modificate tramite Reflection; ecco perché Jackson può modificarli anche se il normale codice Java non può. – StaxMan

2

Avevo bisogno di effettuare il marshalling da GeneratedMessageLite a un oggetto JSON ma non era necessario unmarshal. Non ho potuto usare la libreria protobuf nella risposta di Pangea perché non funziona con l'opzione LITE_RUNTIME. Inoltre, non volevo sovraccaricare il nostro già esistente sistema legacy con la generazione di codice più compilato per i buffer di protocollo esistenti. Per di smistamento a JSON, sono andato con questa semplice soluzione al maresciallo

final Person gpb = Person.newBuilder().setName("Bill Monroe").build(); 
    final Gson gson = new Gson(); 
    final String jsonString = gson.toJson(gpb); 
0

Prima di tutto credo che si debba ragionare con molta attenzione a mettere uno sforzo in conversione di un set di dati per protobuffs. Ecco i miei motivi per convertire un set di dati in protobuffs

  1. Tipo Sicurezza: garanzia sul formato dei dati considerati.
  2. footprint di memoria non compresso dei dati.Il motivo per cui non è compresso è perché la compressione post non ha molta differenza nelle dimensioni di JSON compressi e proto compressi, ma la compressione ha un costo associato. Inoltre, la velocità di serializzazione/de-serializzazione è quasi simile, infatti Jackson Jackson è più veloce dei protobuffs. Per ulteriori informazioni, controllare il seguente link http://technicalrex.com/2014/06/23/performance-playground-jackson-vs-protocol-buffers/
  3. I protocolli devono essere trasferiti sulla rete molto.

Dire che una volta che si converte il set di dati in formato JSON Jackson nel modo in cui la definizione ProtoBuff è definito allora può facilmente essere direttamente mappato in formato ProtoBuff utilizzando il Protostuff: JsonIoUtil: la funzione mergeFrom. Firma della funzione:

public static <T> void mergeFrom(JsonParser parser, T message, Schema<T> schema, boolean numeric) 

riferimento al protostuff

Problemi correlati