Returning height in JSON Response

[colin-axner]

Summary

Returning the height of a query in the JSON Response.

Problem Definition

While there exist workarounds for this, it could be a convenient feature for developers to have access to. However, the current structure of the SDK does not allow for this to be implemented without breaking API. Furthermore, attempting to implement this by breaking the API as little as possible could possibly cause inconsistency and require a lot of unnecessary trade offs.

Proposal

There are a few ways this problem can be approached. Fully break API by adding the following struct in rest.go:

type ResponseWithHeight struct {
    Response   interface{} `json:"response"`
    Height     int64       `json:"height"
}

This would wrap the returned structure with the height it was queried at. This is not an ideal solution since it fully breaks API and because amino encoding is used would show
type:"cosmos-sdk/ResponseWithHeight"
at the top level of the response. It does provide a fairly clean implementation though since ResponseWithHeight just needs to be passed into PostProcessResponse.

Another method is to decode the response in PostProcessResponse into a map and then encode this using the standard JSON library. The code for this can be seen on the last commit of #4573. The basic structure is:

• encode using aminoJSON
• decode into map[string]interface{}
• encode using std json
• write output

While this works, it causes another unwanted side effect. Regular marshaling of structs formats the fields in the order in which they are declared in the struct. Unmarshaling into the map, reorders these fields alphabetically and therefore the returned json response is in a possibly different order than if it had never been decoded into a map.

Another possible but even riskier method is to simply use append to slice in ,"height":x to the end of the json response. This becomes tricky with indenting and is hardcoding so should be avoided.

For the following reasons I have closed #4573, if there is enough developer desire we can revisit this issue. If anyone has any other ideas please feel free to brainstorm on this issue!

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned