/**
* 主要是在工作中学到的一种方法,想法,我觉得这样做很好,所以就记录下来了。如果这样做不科学,请教了。
*
*
*
* @retrun Int code 全局code意义要统一约定好,其余的要在接口文档中做出说明。通常返回是接口响应状态
* (这点比较重要,因为有些开发会误会这是服务器响应code,如果需要服务器编程,可以将这个code处理成服务器响应code返回出去。)
*
* @retrun String msg 提示信息应该写个类,根据需求和请求方向返回对应提示信息。
* (这里是因为我现在这个项目,我们开发的接口要提供给 PC和移动端(ios和安卓)使用,其设计的产品页面逻辑有时候不一样。前端采用Vue做前后端分离,所以这里在处理的时候可以考虑些怎么做。)
*
* @retrun 绑定对象 data 这里根据接口场景,查询没数据时候返回null或不返回;操作成功后返回null或不返回,且请求不成功 或 请求参数错误等等其他情况的时候也可以返回null或不返回。这个在自己封装的返回格式的方法里去改就可以了。
*
* @retrun 版本号 version
*
* 下面的例子场景:
* 通过接口返回 订单详情
*/
$result =
[
'code' => 200,
'msg' => '请求成功',
'version' => '版本号 -- 0.0.0'
'data' =>
[
'public' => //接口返回数据对象中,不用拆分的,固定需要的一些信息放在里面。如下面的买卖放的信息可以放进来,不过因为我觉得这样安逸点,就这么放了。
[
'openid' => '订单对象的openid,这种id需要唯一,自主生产,通常32位',
'status' => '订单状态:待付,已付,送货中,已收货等等',
'ctime' => //订单创建时间
[
'date' => '2018-01-18'
'unix' => 1516263255
]
],
'detail' => //商品信息集合,这里主要是为了好让数据以这种格式让客户端在类表格的页面中调用
[
[ //这里加个 [] 是因为 有些需求是一个订单里有很多商品,每个商品就是一个这样格式的[]
'name' => '商品名称',
'number' => '商品数量',
'unit' => '商品单位',
'specifications' => //存在商品规格的信息,通过SQL联查得出。
[
[
'key' => '长',
'value' => '1.3',
'unit' => '米'
//,....
],
[
'key' => '宽',
'value' => '1',
'unit' => '米'
]//,..
]//,...
]//,...
],
'seller' => //卖方信息集合
[
'user' => //卖家信息集合
[
'openid' => '卖家id',
'name' => '卖家昵称',
'img' =>
[
'big'=>'用户头像大图',
'medium'=>'用户头像中图',
'small'=>'用户头像小图',
]
],
'store' => //店铺信息集合
[
'openid' => '店铺id',
'name' => '店铺名称',
'level' => '店铺等级',
'logo' =>
[
'big'=>'店铺logo大图',
'medium'=>'店铺logo中图',
'small'=>'店铺logo小图',
]
//,...
]
],
'buyer' => []//买家信息集合,包括用户id,名称等等信息
]
]
/*
怎么返回数据格式每个人都有不同的理解,怎么返回只要能做到当需求改变的时候,能灵活的将信息加在对应格式分类下,然后自己在看格式的时候能看得明白哪一块是哪些数据就行了。
写api就是写服务的感觉,所以在考虑返回格式的时候,其实只要多考虑下让服务端在一次遍历之后就能完成页面数据的渲染就好,一切跟着需求走,最好的就是我们把页面展示的文字性的东西都返回出来,这样啥东西后台都能控制了,然后客户端只用拉,不用花太多时间来处理数据的问题了,以为在返回的时候,api就处理好了。
*/
api 返回数据
最新推荐文章于 2024-08-29 17:40:26 发布