Invoer (.proto-schema)

Uitvoer (JSON-voorbeeld)

Wat deze tool doet

Je hebt een Protocol Buffers-schema en je hebt een JSON-voorbeeld nodig van hoe een van die messages eruitziet — voor een test-fixture, een OpenAPI-voorbeeld, een gestubde gRPC-response, wat dan ook. Met de hand een JSON-vorm uittypen vanuit een lange .proto-file is saai en foutgevoelig. Deze converter leest het schema, pakt de laatst gedeclareerde message (typisch het "buitenste" type) en geeft een JSON-object dat veld-voor-veld klopt.

De uitvoer gebruikt de officiële proto3-default-waarden: lege string voor string en bytes, 0 voor numerieke types, false voor bool, [] voor repeated, {} voor map en de zero-valued enum-constante voor enum-velden. Geneste messages worden recursief uitgeklapt. 64-bit integers komen er als JSON-strings uit, conform de proto3-JSON-mapping-spec — je kunt een int64 niet in een JS Number stoppen zonder precisie te verliezen.

Alles gebeurt lokaal in je browser — geen .proto-upload, geen schema dat naar een server gaat, geen inferentie-call. Gewoon een zelfgebouwde parser die overweg kan met syntax/package/import-directives, commentaar (regel en blok), geneste message- en enum-blokken, oneof, map<K, V>, repeated, optional en field options (worden gelezen maar genegeerd). Als je een volledige protobufjs-stijl runtime nodig hebt, dat is een ander probleem — maar voor "geef me een JSON-vorm uit dit schema" is dit sneller.

Hoe te gebruiken

Drie stappen. De uitvoer-JSON is meteen klaar om in een fixture, een voorbeeldblok of een request body te plakken.

Plak je .proto-schema

Dump het schema in de linker editor. syntax = "proto3"; bovenaan is prima maar optioneel — de parser maalt er niet om. Commentaren, package-declaraties en import-statements worden allemaal netjes overgeslagen. Heb je meerdere messages, dan gebruikt de parser de laatste top-level message (typisch het buitenste/samengestelde type) als root.

Wil je een andere message converteren? Verplaats de message die je wilt naar de onderkant van het bestand. Het schema mag geneste types, enums en oneof-blokken bevatten — alles wordt opgelost.

Klik op Convert

Klik op de groene Convert-knop. De parser tokeniseert het schema, bouwt een message-boom en loopt de root message af met proto3-defaults voor elk veld. Geneste messages worden inline uitgeklapt. repeated-velden produceren een array van één element als hint voor de element-vorm — een lege array zou de structuur niet tonen.

Gebruik de JSON

Kopieer het resultaat naar je test-fixture, je OpenAPI-voorbeeldblok, je gRPC-Web-mock of waar je maar een request/response-vorm nodig hebt. De keys komen exact overeen met de veldnamen in het .proto — zet later om naar camelCase als je codegen dat doet.

Wanneer dit echt tijd bespaart

gRPC-responses stuben voor tests

Je service handler retourneert een Protobuf-response. De unit test heeft een JSON-fixture nodig die past bij de message-vorm. Plak het <code>.proto</code>, pak de JSON, gooi het in je fixtures-map. Geen 30 velden meer met de hand intypen en er één vergeten.

OpenAPI-voorbeelden voor een gRPC-gateway

Draai je grpc-gateway of iets soortgelijks om Protobuf-services als REST aan te bieden? Elke operation wil een JSON-voorbeeld. Converteer elke .proto-message naar een JSON-skelet en plak het onder de example-key in je spec.

Een JSON Schema bootstrappen

Je wilt JSON-requests valideren die aan een <code>.proto</code>-contract voldoen. Converteer eerst naar een JSON-voorbeeld, geef dat aan een JSON-Schema-from-sample-tool en je hebt binnen seconden een startschema.

Request bodies invullen in API-clients

Test je een HTTP-getranscodeerde gRPC-API in Postman of met curl? Plak het .proto, kopieer het JSON-skelet naar de request body, vul de waarden in die je echt wilt sturen.

Veelgestelde vragen

Wordt mijn .proto-schema ergens heen gestuurd?

Nee. Het parsen gebeurt volledig in je browser via JavaScript. Niets van je schema — message-namen, veldnamen, package-paden — verlaat je machine. Open de DevTools en kijk op het Network-tabblad terwijl je Convert klikt. Nul requests.

Werkt het ook met proto2 of alleen proto3?

Grotendeels. De parser kan om met proto2-syntax-tokens als required en optional, maar de uitvoerwaarden gebruiken proto3-defaults (precies wat de proto3 JSON-mapping voorschrijft). Heb je een proto2-bestand met expliciete defaults via [default = ...], dan worden die defaults niet in de uitvoer toegepast.

Hoe kiest het welke message het converteert?

Het neemt de laatste top-level message die in het bestand is gedeclareerd. In echte schema's wordt het buitenste/samengestelde type meestal na zijn dependencies gedeclareerd, dus dat klopt vaak met wat je wilt. Pakt het de verkeerde, herorden het bestand zodat de gewenste message als laatste staat.

Waarom zijn int64-waarden strings in de uitvoer?

Omdat JSON alleen IEEE-754 doubles kent, die boven 2^53 precisie verliezen. De officiële proto3 JSON-mapping vraagt dat int64, uint64, fixed64, sfixed64, sint64 worden gecodeerd als JSON-strings. We volgen die conventie.

En oneof, map en repeated?

Alle drie werken. oneof-velden worden geparsed als gewone velden (het JSON-object bevat ze allemaal in plaats van er één te kiezen — typisch verwijder je de niet-gewenste). map<K, V> levert een leeg {}-object. repeated levert een array van één element die de element-vorm laat zien — dupliceer of verwijder om bij je echte data aan te sluiten.

Volgt het imports?

Nee. import-statements worden herkend en overgeslagen. Cross-file message-types resolven naar null in de uitvoer. Heb je cross-file resolutie nodig, plak dan de relevante messages uit de geïmporteerde bestanden in dezelfde invoer.

Hoe groot mag het schema zijn?

Tienduizenden regels, geen probleem. Alles is lokaal, dus geen upload, geen rate limit, geen netwerk-latency.

Gerelateerde tools

Als je met Protobuf, JSON en schema's in de weer bent, passen deze goed bij elkaar:

Protobuf naar JSON Converter