It would make great sense for paged results array property to have a common name, items perhaps.

For those writing in languages that support 'generic' constructs, this would simplify the code dramatically. e.g. PagedResult<Users>.

For those writing in languages that don't support 'generic' constructs, nothing has changed except the name of the field.

1 Answer 1


It would make more sense - in my opinion - for a library to abstract the paged nature of results away entirely.

Furthermore, there's no need for the objects exposed by whatever deserialization code to reflect the naming scheme of the underlying JSON. If you want more automatic code, you could just define the data field as not total, page, or pagesize. The general case for API usage does assume a human reading the docs and writing the code, your efforts not withstanding.

A change with such a wide impact - literally every method in the API - isn't really practical this late in the beta cycle unless it were addressing a very real problem, which this frankly isn't.

  • asked and answered - and you posit an obvious solution that i did not consider. thanks. Jun 6, 2010 at 4:42
  • considered deleting this question. do you think it has value? Jun 6, 2010 at 9:00
  • 1
    @codepoet: I think you should leave it. It's a good question. Jun 6, 2010 at 10:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .