007-整理细枝末节

基于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顺序插入替换
比较费后端资源

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

有空再细细修改完善

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,049评论 18 139
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 170,471评论 25 707
  • # 一度蜜v3.0协议 --- # 交互协议 [TOC] ## 协议说明 ### 请求参数 下表列出了v3.0版协...
    c5e350bc5b40阅读 620评论 0 0
  • 晚上下班,忽然看到关闭很久的洗衣店开门了,兴冲冲跑过去,想要问个究竟。因为洗衣店关了大半年之久,而我还有一...
    笨牛宝贝214阅读 206评论 0 0
  • 虽然春天已经到了,但是很多地方的气温仍然比较低,所以毛衣仍然是人们保暖、装饰不可缺少的服饰。那么毛衣链如何搭配好看...
    侃珠宝聊时尚阅读 332评论 0 0