<p>Hello gophers, it is fairly common to come across an api that has a json wrapper class, so requests look something like this,</p>
<pre><code>{
"status": "ok",
"type": "type1",
"body": {
"var1": "key1",
"var2": "key2"
}
}
{
"status": "ok",
"type": "type2",
"body": {
"var3": "key3",
"var4": "key4"
}
}
</code></pre>
<p>in languages like java/c# I usually use a generic JsonObject to represent the body then cast to my concrete class after a switch.</p>
<p>Do you know of a good idiomatic way of doing this? </p>
<p>Preferably w.o having to unmarshal twice.</p>
<p>Thanks</p>
<p>Edit:
Looks like you do have to unmarshal twice.. but this works well
<a href="https://play.golang.org/p/gf7TZmX6AV">https://play.golang.org/p/gf7TZmX6AV</a></p>
<hr/>**评论：**<br/><br/>jerf: <pre><p>A lot of languages that make it look like they aren't unmarshalling twice still kind of are behind the hood. They parse the JSON into a generic representation, like the one <code>encoding/json</code> gives for <code>map[string]interface{}</code>, and then marshal that into the final target object. While probably still better than the double-parse Go does, it's less advantageous over Go than it may initially seem. By contrast, if you do know the type you're going into, Go does marshal directly into the correct objects. (<code>encoding/json</code> then loses a bit again due to being reflection based. If that's a problem there are some packages that will generate code for you instead of using reflection.)</p>
<p>I've used this approach for some fairly wide cross-language communication and I can't say any language is really <em>good</em> at this. The problem is fundamental to JSON; you have no control over the order of the incoming keys, and there is nothing you can do about the possibility that the "type" key will come last, after megabytes or gigabytes of other stuff, all of which you need to hold in some sort of holding pattern until then.</p>
<p>If that's a real problem, then you just determined that you can't use JSON to solve your problem. Of course it often isn't a real problem, but if it is, you'll have to leave JSON behind. It's a nifty little default and great for cross-language support, but it's definitely a lowest-common-denominator sort of serialization format, not really the best at anything except being cross-platform.</p></pre>twek: <pre><blockquote>
<p>used this approach for some fairly wide cross-language communication and I can't say any language is really good at this. The problem is fundamental to JSON; you have no control over the order of the incoming keys, and there is nothing you can do about the possibility that the "type" key will come last, after megabytes or gigabytes of other stuff, all of which you need to hold in some sort of holding pattern until then.</p>
</blockquote>
<p>Thanks for taking the time to write this,
I am happy enough with the RawMessage approach as the messages I am dealing with are small, </p>
<p>thanks!</p></pre>pierrrre: <pre><p><a href="https://golang.org/pkg/encoding/json/#RawMessage">https://golang.org/pkg/encoding/json/#RawMessage</a>
?
Use it to decode your embedded object later, with the right type.</p></pre>twek: <pre><p>Like this?
<a href="https://play.golang.org/p/gf7TZmX6AV" rel="nofollow">https://play.golang.org/p/gf7TZmX6AV</a></p></pre>pierrrre: <pre><p>Yes!</p></pre>demitriousk: <pre><p>in cases like this you'd want to use json.RawMessage for the body part of your struct... Then you would unmarshal body into a seperate and appropriate struct for your needs based on the contents of status and type.</p></pre>twek: <pre><p>Like this?
<a href="https://play.golang.org/p/gf7TZmX6AV" rel="nofollow">https://play.golang.org/p/gf7TZmX6AV</a></p></pre>
