基于json的数据传输设计 - 整理细枝末节

1. 脱离贫困 - 满足基本需求
2. 走向小康 - 丰满格式设计
3. 提升精神 - 添加容错机制
4. 加强品质 - 加固安全机制
5. 开放眼界 - 整体框架设计
6. 追求真理 - 实践博客系统
7. 茶余饭后 - 整理细枝末节

1. restful思考
   现在对于前后端数据传输最火热的思想莫过于对restful的的讨论了,对于什么是restful,这里不做详细的表述,只是做一些简单的解释.
   所谓的restful,其实我们得从url说起,url即统一资源定位符,在web世界里,所有的东西都是资源,一张网页,一张图片,一个css,一个js,都是资源,而我们总是可以通过一个链接访问到该资源,那便是url.
   而restful便是以url为资源定位,http协议动作为操作方式的一种设计.比如现在有article这种资源,那么我们如何访问这个资源呢?假定访问这个资源的url为{server_url}/article,那我们就有一下几种访问方式

   • get : {server_url}/article:{article_id} :获取一片文章
   • get : {server_url}/article : 获取所有文章
   • post : {server_url}/article:{article_id} 添加一片文章
   • delete : {server_url}/article:{article_id} 删除一片文章
   • fetch : {server_url}/article:{article_id} 更新一片文章
     在上一篇文章中,其实也利用了这种思想,但是也不全是,因为我抛弃了http的多种动作,而全部采用post方式,在但是在命名上,还是采用很restful的方式来命名
   • {serve_url}/article/get
   • {serve_url}/article/create
   • {serve_url}/article/update
   • {serve_url}/article/delete
     总的来说,restful只是一种思想,而非银弹或者准则,只是提出了一种更优雅的设计方式,见仁见智.

2. 资源复用
   在之前的设计中,我们说了一种面向对象的数据结构设计,其实这是为了符合面向对象的设计思想,为了实体的可复用性.什么叫做实体可复用性呢?
   假定现在有两个接口:

   • ARTICLE_GET : 获取所有的文章(包含文章分类)
   • ARTICLE_GROUP_GET : 获取文章的分组
   • ARTICLE_GET_BY_GROUP : 根据分类获取文章
     在页面和需求上的提现便是:
   • 有一个分类导航,用户点击分类导航中的分类,可以获取到该分类下的所有文章
   • 有一个文章列表,用户可以看见文章的标题,文章的分类,文章的发布时间
   • 用户点击文章中的文章分类,则可以跳转到该分类下的所有文章
     在ARTICLE_GROUP_GET接口上,我们其实是没有分歧的:

   {
       "id":1,
       "name":"技术分类"
   }
   

   分歧在于其他两个接口,这两个接口的返回数据其实是一样的,他们的区别在于查询方式的不同,所以其实可以合并成一个接口,

   • 满足需求1

   {
       "id":1,
       "title":"文章标题",
       "create_time":"发布事件"
   }
   

   这里只是简单满足了需求1

   • 满足需求2和3

   {
       "id":1,
       "title":"文章标题",
       "create_time":"发布事件",
       "group_id":1,
       "group_name":"分组名称"
   }
   

   这里看是满足了需求2和3但是却有些问题,对于文章分组的信息,我们在字段之前添加了group_前缀,看似优雅的区分了文章资源和分组资源,但是如果照此设计,一旦单个资源扩大起来,将变得不可读,同时也抛弃了group自身这个资源,所以我们必须修改一下设计

   {
       "id":1,
       "title":"文章标题",
       "create_time":"发布事件",
       "group":{
           "id":1,
           "name":"文章分组"
       }
   }
   

   这样一来便可以达到可读性和可维护性的提升,同时复用了group这个资源,达到资源嵌套和复用.
   但是,在达到资源复用的同时,要避免资源的过分复用,比如一片文章中有3张图片,那么这么设计是不对的:

   [
       {
           "id":1,
           "url":"http://img_url"
       }, {
           "id":2,
           "url":"http://img_url"
       } {
           "id":3,
           "url":"http://img_url"
       }
   ]
   

   这里的解决方案应当是直接合并为一条

   {
       "imgs":"http://img1_url;http://img2_url;img3_url;"
   }
   

3. id作为资源标识
   在所有的资源中,使用一个统一的键名来作为资源的标识,我惯用的便是id

4. 列表和详情的获取分离
   在api设计中,常常有一种需求,比如一个博客,有列表页面和详情页面之分,这里有三种解决方案

   • 获取列表的时候将所有数据返回,从列表页跳转到详情页面的时候直接将之前的数据同步推送过去
     • 如果单个资源数据过大,比如博客文章可能包含该一个富文本,将会导致获取事件过长
     • 跳转延迟
   • 获取列表的时候获取全部数据,跳转的时候推送id过去,详情页通过id获取该资源
     • 如果单个资源数据过大,比如博客文章可能包含该一个富文本,将会导致获取事件过长
     • 同时重复获取资源导致资源浪费
   • 获取列表的时候获取必须数据,跳转的时候推送id过去,详情页通过id获取全部数据
     • 资源不统一
       综合考虑,第三种方案其实是最优的,但是还是要把他的不足解决,解决方案便是,在列表接口吧不需要的数据或者不需要的大数据直接置空但是保留键值对.比如文章列表页面吧文章正文字段置空,而在详情页面吧正文字段恢复,这样既保持了资源的统一,也保证了传输的速度

5. 列表分页
   常见需求

   • 前端假分页 : 前端获取50条,单次显示10条
     • 显示到40条的时候再次获取数据,每次刷新都很快的感觉
   • 前端真分页 : 前段获取50条,显示50条
     • 每次都要获取,暴露了获取时间,需要等待
   • 后端假分页 : 查询全部数据,返回10条
     • 浪费资源
   • 后端真分页 : 查询50条,返回50条
     • 合理利用资源
       最好的方案是 : 前端假分页结合后端真分页

6. 资源存储
   不应该吧图片或者其他大型资源直接存储到数据中,比如富文本中的图片,如果直接以blob存储到数据库中,在获取的时候是单线程堵塞的,应当将图片等文件存储到硬盘中,在富文本中保留链接,获取的时候减轻数据传输的同时将会以一步线程的方式访问图片音乐等资源

*7. id加密策略
将id用前后端协同好的算法加密,比如
- 生成32位随机字母字符串(不包含数字)
- 将id顺序插入替换
比较费后端资源

8. 更加合理利用http协议
   • 将token验证放入header中的x-auth-token
   • 将code用http code代替

有空再细细修改完善