Dependence on column order in response to Smartsheet "Get Sheet" API

Question about the “Get Sheet” API, namely https://api.smartsheet.com/2.0/sheets/{sheetId} –

This API responds with (among other things) an array of columns and an array of rows. Each row in the array of rows contains an array of cells.

Can we be guaranteed in any invocation of this API that the columns in the array are presented in the exact order as the cells in each row, and that every row will have an array of cells that is the exact same array-length as the array of columns?

In other words, if we determine an indexed-mapping into the column array, can we definitively use that same index mapping into the cells on each row?

If so, is there a reason this is not documented? Can it be counted on into the future?

I'll address your questions one at a time.

Question #1:

In a Get Sheet response, is it guaranteed that the items in the columns array will be presented in the same order as the items in the cells array of each row object?

Answer:

In many years of working with the Smartsheet API, I've always observed this to be true. However, just because it's worked this way until now doesn't necessarily mean that it's guaranteed to work this way in the future. In fact, Smartsheet API documentation specifically advises that you don't assume any certain order of JSON objects in API responses. From the Versioning and Changes section of the docs:

Question #2:

In a Get Sheet response, is it guaranteed that every item in the rows array will contain an array of cells that's the exact same array-length as the columns array?

Answer:

In many years of working with the Smartsheet API, I've always observed this to be true. Seems like you should be able to count on this always being true, as changing this type of behavior in the API would seem like a 'breaking change' -- i.e., the type of change that Smartsheet shouldn't introduce without releasing a new version the API.

Question #3:

If we determine an indexed-mapping into the column array, can we definitively use that same index mapping into the cells on each row?

Answer:

As explained above, this approach should work based on how the API behaves today (assuming that you're creating the mapping at runtime for each Get Sheet response). But there's no guarantee that it'll continue to work in the future, as Smartsheet doesn't guarantee the order of items returned in API responses. A safer bet would be to implement logic that verifies this assumption at runtime for each Get Sheet response -- i.e., for each item in the columns array, read the id and index properties and verify that the same columnId exists at the same index within the first row object's array of cells.