# 第二章-对比传统RESTful

# 2.对比传统RESTful方式

TIP

2.对比传统RESTful方式

# 2.1 开发流程

开发流程	传统方式	APIJSON
接口传输	等后端编辑接口，然后更新文档，前端再按照文档编辑请求和解析代码	前端按照自己的需求编辑请求和解析代码。没有接口，更不需要文档！前端再也不用和后端沟通接口或文档问题了！
兼容旧版	后端增加新接口，用v2表示第2版接口，然后更新文档	什么都不用做！

# 2.2 前端请求

前端请求	传统方式	APIJSON
要求	前端按照文档在对应URL后面拼接键值对	前端按照自己的需求在固定URL后拼接JSON
URL	不同的请求对应不同的URL，基本上有多少个不同的请求就得有多少个接口URL	相同的操作方法(增删改查)都用同一个URL，大部分请求都用7个通用接口URL的其中一个
键值对	key=value	key:value
结构	同一个URL内table_name只能有一个 base_url/get/table_name? key0=value0&key1=value1...	同一个URL后TableName可传任意数量个 base_url/get/ { TableName0:{ key0:value0, key1:value1, ... }, TableName1:{ ... } ... }

# 2.3 后端操作

后端操作	传统方式	APIJSON
解析和返回	取出键值对，把键值对作为条件用预设的的方式去查询数据库，最后封装JSON并返回给前端	把Parser#parse方法的返回值返回给前端就行
返回JSON结构的设定方式	由后端设定，前端不能修改	由前端设定，后端不能修改

# 2.4 前端解析

前端解析	传统方式	APIJSON
查看方式	查文档或问后端，或等请求成功后看日志	看请求就行，所求即所得，不用查、不用问、不用等。也可以等请求成功后看日志
解析方法	用JSON解析器来解析JSONObject	可以用JSONResponse解析JSONObject，或使用传统方式

# 2.5 前端对应不同需求的请求

前端的请求	传统方式	APIJSON
User	base_url/get/user?id=38710	base_url/get/ { "User":{ "id":38710 } } (opens new window)
Moment和对应的User	分两次请求 Moment: base_url/get/moment?userId=38710 User: base_url/get/user?id=38710	base_url/get/ { "Moment":{ "userId":38710 }, "User":{ "id":38710 } } (opens new window)
User列表	base_url/get/user/list? page=0&count=3&sex=0	base_url/get/ { "User[]":{ "page":0, "count":3, "User":{ "sex":0 } } } (opens new window)
Moment列表，每个Moment包括 1.发布者User 2.前3条Comment	Moment里必须有 1.User对象 2.Comment数组 base_url/get/moment/list? page=0&count=3&commentCount=3	base_url/get/ { "[]":{ "page":0, "count":3, "Moment":{}, "User":{ "id@":"/Moment/userId" }, "Comment[]":{ "count":3, "Comment":{ "momentId@":"[]/Moment/id" } } } } (opens new window)
User发布的Moment列表，每个Moment包括 1.发布者User 2.前3条Comment	1.Moment里必须有User对象和Comment数组 2.字段名必须查接口文档，例如评论数量字段名可能是 commentCount,comment_count或者简写cmt_count等各种奇葩写法... base_url/get/moment/list? page=0&count=3 &commentCount=3&userId=38710	有以下几种方式: ① 把以上请求里的 "Moment":{}, "User":{"id@":"/Moment/userId"} 改为 "Moment":{"userId":38710}, "User":{"id":38710} (opens new window) ② 或把User放在上面的最外层省去重复的User base_url/get/ { "User":{ "id":38710 }, "[]":{ "page":0, "count":3, "Moment":{ "userId":38710 }, "Comment[]":{ "count":3, "Comment":{ "momentId@":"[]/Moment/id" } } } } (opens new window) ③ 如果User之前已经获取到了，还可以不传User来节省请求和返回数据的流量并提升速度 base_url/get/ { "[]":{ "page":0, "count":3, "Moment":{ "userId":38710 }, "Comment[]":{ "count":3, "Comment":{ "momentId@":"[]/Moment/id" } } } } (opens new window)

# 2.6 后端对应不同请求的返回结果

后端的返回结果	传统方式	APIJSON
User	{ "data":{ "id":38710, "name":"xxx", ... }, "code":200, "msg":"success" }	{ "User":{ "id":38710, "name":"xxx", ... }, "code":200, "msg":"success" }
Moment和对应的User	分别返回两次请求的结果，获取到Moment后取出userId作为User的id条件去查询User Moment: { "data":{ "id":235, "content":"xxx", ... }, "code":200, "msg":"success" } User: { "data":{ "id":38710, "name":"xxx", ... }, "code":200, "msg":"success" }	一次性返回，没有传统方式导致的长时间等待结果、两次结果间关联、线程多次切换等问题 { "Moment":{ "id":235, "content":"xxx", ... }, "User":{ "id":38710, "name":"xxx", ... }, "code":200, "msg":"success" }
User列表	{ "data":[ { "id":38710, "name":"xxx", ... }, { "id":82001, ... }, ... ], "code":200, "msg":"success" }	{ "User[]":[ { "id":38710, "name":"xxx", ... }, { "id":82001, ... }, ... ], "code":200, "msg":"success" }
Moment列表，每个Moment包括发布者User和前3条Comment	Moment里必须有 1.User对象 2.Comment数组 { "data":[ { "id":235, "content":"xxx", ..., "User":{ ... }, "Comment":[ ... ] }, { "id":301, "content":"xxx", ..., "User":{ ... }, ... }, ... ], "code":200, "msg":"success" }	1.高灵活，可任意组合 2.低耦合，逻辑很清晰 { "[]":[ { "Moment":{ "id":235, "content":"xxx", ... }, "User":{ ... }, "Comment[]":[ ... ] }, { "Moment":{ "id":301, "content":"xxx", ... }, "User":{ ... }, ... }, ... ], "code":200, "msg":"success" }
User发布的Moment列表，每个Moment包括发布者User和前3条Comment	1.大量重复User，浪费流量和服务器性能 2.优化很繁琐，需要后端扩展接口、写好文档，前端/前端再配合优化 { "data":[ { "id":235, "content":"xxx", ..., "User":{ "id":38710, "name":"Tommy" ... }, "Comment":[ ... ] ... }, { "id":470, "content":"xxx", ..., "User":{ "id":38710, "name":"Tommy" ... }, "Comment":[ ... ] ... }, { "id":511, "content":"xxx", ..., "User":{ "id":38710, "name":"Tommy" ... }, "Comment":[ ... ] ... }, { "id":595, "content":"xxx", ..., "User":{ "id":38710, "name":"Tommy" ... }, "Comment":[ ... ] ... }, ... ], "code":200, "msg":"success" }	以上不同请求方式的结果: ① 常规请求 { "[]":[ { "Moment":{ "id":235, "content":"xxx", ... }, "User":{ "id":38710, "name":"Tommy" ... }, "Comment[]":[ ... ] }, ... ], "code":200, "msg":"success" } ② 省去重复的User { "User":{ "id":38710, "name":"Tommy", ... }, "[]":[ { "Moment":{ "id":235, "content":"xxx", ... }, "Comment[]":[ ... ] }, ... ], "code":200, "msg":"success" } ③ 不查询已获取到的User { "[]":[ { "Moment":{ "id":235, "content":"xxx", ... }, "Comment[]":[ ... ] }, ... ], "code":200, "msg":"success" }

1.base_url指基地址，一般是顶级域名，其它分支url都是在base_url后扩展。如base_url:http://apijson.cn:8080/ ，对应的GET分支url:http://apijson.cn:8080/get/ 。下同。
2.请求中的key或value任意一个为null值时，这个 key:value键值对被视为无效。下同。
3.请求中的 / 需要转义。JSONRequest.java已经用URLEncoder.encode转义，不需要再写；但如果是浏览器或Postman等直接输入url/request，需要把request中的所有 / 都改成 %252F 。下同。
4.code，指返回结果中的状态码，200表示成功，其它都是错误码，值全部都是HTTP标准状态码。下同。
5.msg，指返回结果中的状态信息，对成功结果或错误原因的详细说明。下同。
6.code和msg总是在返回结果的同一层级成对出现。对所有请求的返回结果都会在最外层有一对总结式code和msg。下同。
7.id等字段对应的值仅供说明，不一定是数据库里存在的，请求里用的是真实存在的值。下同。

← 第一章-实例代码第三章-设计规范 →