我正在编写一个REST API,想知道天气这是一个好习惯。
以下是JSON响应示例。
错误回复,
{
"code": 1100,
"status": false,
"message": "Values of imei/email/pin cannot be empty.",
"server_time": "2013-11-28 09:13:06"
}
成功响应,没有一些数据
{
"code": 200,
"status": true,
"data": {
"id": "2",
"isNewParent": false,
"firstName": null,
"lastName": null,
"dob": null,
"gender": null,
"username": null
},
"server_time": "2013-11-28 09:07:23"
}
成功响应,包含数据
{
"code": 200,
"status": true,
"data": {
"id": "3",
"isNewParent": true,
"firstName": "Saman",
"lastName": "kalhara",
"dob": 2002-10-29,
"gender": 0,
"username": 'saman88'
},
"server_time": "2013-11-28 10:07:23"
}
问题是,关于没有数据的成功响应,一些移动开发人员正在请求json响应仅包含带有值的标记,并跳过空值。所以它看起来像,
{
"code": 200,
"status": true,
"data": {
"id": "2",
"isNewParent": false,
},
"server_time": "2013-11-28 09:07:23"
}
我陷入了两难的境地。我更喜欢它的完成方式,并且想知道这是否会导致API请求性能的任何缓慢。
答案 0 :(得分:2)
它不应该导致任何缓慢。如果有的话,你减少了必须是JSON的键/值的数量。但是,除非您收到难以想象的流量且未缓存,否则删除null
值不会对性能造成任何巨大影响。
然而,在这种情况下,我会说最好的做法取决于你父亲的存储方式。我不明白某些东西可以有ID,但没有用户名,dob,性别,名字或姓氏。有这个原因吗?
除非ID有意义,否则我对这两种解决方案的反击都是这样的回应:
{
"code": 200,
"status": true,
"data": {},
"server_time": "2013-11-28 10:07:23"
}
此外,如果您想严格遵守REST,则应使用内置HTTP状态代码,并且只有在HTTP状态无法完全解释响应时才添加其他错误信息。
鉴于响应应返回数据,我会说为了保持一致性,您应该为包含数据的每个响应维护一个常量结构。通过这种方式,开发人员不必进行过多检查,以确保在检索它们之前定义了所需的所有字段。确定是否定义了字段就像data['field'] === null
一样简单,所以我不理解开发人员的动荡。如果他们的投诉是以保存字节为基础的,除非他们发出数千个请求,否则在数据对象中包含一些空值根本不会产生太大的影响。