app后端设计.pdfVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
app后端设计

app 后端设计 目录 前言2 app 后端设计(1)—api3 app 后端设计(2)--xmpp 的使用7 app 后端设计(3)--短信,邮件,推送服务9 app 后端设计(4)--通讯的安全性10 app 后端设计(5)--表情的处理12 app 后端设计(6)--LBS 13 app 后端设计(7)--项目管理16 app 后端设计(8)--数据库分表19 app 后端设计(10)--数据增量更新21 app 后端设计(11)--系统架构27 app 后端设计(12)-- 图片的处理28 作者:曾健生,博客专栏:/newjueqi ,qq:190678908 app 后端设计 前言 曾经,我也是一直从事网站后台的开发,因为一些机缘,踏进了移动app 后台,之前对 app 后台没什么了解。 曾经,我们连续一个月从早上9 点工作到晚上10 点,就为了改进后台的架构,提供性 能,让LBS 的服务响应时间从十多秒提升到1 秒内。 曾经,我觉得app 后台架构上和传统的网站上有很大的区别,现在发现,其实很多思想 都是通用的。 曾经,我在后台架构犯过很多问题。有一天,忽然想:如果把遇到的问题的解决方案都 记录下来,不就能让别人少走弯路吗?于是,就有了“app 后端技术架构”这个技术专栏 (/column/details/mobilebackend.html) 后来我又想,为啥不建立一个后台交流的qq 群,把对这方面有兴趣的小伙伴集在一起, 大家互相交流学习呢?于是,就有了“app 后端技术”qq 群:254659220 为了方便小伙伴阅读《app 后端设计》系列文章,于是我就把这系列文章制作成下面一 个文档。这个文档上的文章,大多数是本人在2012,2013 年中开发社交app 后台时的工作的 总结,现在看来,很多技术性的东西都已经过时了,但有些思想上的东西,还是有一定的参 考价值。请阅读文档的各位小伙伴注意:最新的文章,请到本人的博客 (/newjueqi)上阅读,我会不定期更新里面的内容。 分享越多,收获越多!!! 作者:曾健生,博客专栏:/newjueqi ,qq:190678908 app 后端设计 app 后端设计(1)—api (1) Restful 设计原则 Restful 风格:RESTfu 设计原则,它被Roy Felding 提出(在他的”基于网络的软件架构“论 文中第五章)。而 REST 的核心原则是将你的API 拆分为逻辑上的资源。这些资源通过 http 被操作(GET ,POST,PUT,DELETE )。 但现在看,一般的操作只有两种:GET ,POST 。 这个设计原则最简单的应用就是根据object 而不是页面来设计api 。最开始的时候,app 的一个页面需要什么数据,api 就返回什么数据。结果随着app 的UI 不断改版,需要的数据 不断变化,不停地修改 api,最后当api 的改动会影响以前的版本的时候,只能写一个新的 api 版本,最后弄得api 中有很多_V2,V3 这样的标志,恶梦! 后来在网站的重构过程中,就根据object 来设计api,但根据object 来设计,又有一个 问题,一个大object 可能包含很多小object,是一个api 返回全部小object,还是分为多个 api 返回?根据业务和技术,带宽等仔细考虑吧。 (2) api 的命名 其中一个原则,一看api 名字就知道这个api 是干啥。在创业团队中,一般就只有一个 人负责后台,当你要负责几十甚至上百个api,你就知道不能“望名知api”是个什么样的痛 苦。 (3) 安全性 请看 /newjueqi/article/details (4) api 返回数据 app 客户端的语言 java 和object-c 都是强类型语言,所以怎么处理空值显得特别重要, 不合理的设计很容易造成app 的闪退。 从后台的角度来说,api 中返回的数据中,正确值和空值的类型必须一样,举例,用户 名的字段是“rea

文档评论(0)

牛X文档 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档