对于一个商品App页面，一般不会直接显示商品列表。而是对商品分类，展示多个分类的商品信息
来增加用户点击，带动收入。分类像热门，运动，女性，数码这些。可能对应的接口可是就是类似下面
的格式：

 {
      errno: "0",
      end_state: "1",
      total: "-1",
      data: {
          hot: {
              data: []
          },
          sport: {
              data: []
          },
          it: {
              data: []
          },
          xx: {
              data: []
          },
      }
}

对应到客户端也是直接解析具体字段并分类展示，还可能会存在部分硬编码。编程珠玑中提到 数据决定
程序结构 ， 那么什么决定数据结构呢？ 业务需求！ 上面接口数据格式，要是业务要增加一个分类呢？
服务接口添加业务逻辑，添加分类字段。客户端也要开发，等发版，放量，最后展示到用户整个周期是很长的。这种接口格式很难扩展功能。 怎么才能易于扩展呢？看看下面的格式：

 {
      errno: "0",
      end_state: "1",
      total: "-1",
      data: {
          {
              desc: hot,
              data: []
          },
          {
              desc: sport,
              data: []
          },
          {
              desc: it,
              data: []
          },
          {
              desc: xx,
              data: []
          },
      }
}

这种格式客户端不需要知道有多少分类，data里面每个元素就是一个分类，分类里面有自己的描述信息，
数据信息。若要添加分类，只要服务端添加分类数据就行。线上直接生效，避免了客户端开发，发版，放量。