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)    安全性,请看 http://blog.csdn.net/newjueqi/article/details/18887571 

(4) api返回数据

    app客户端的语言 java 和object-c都是强类型语言,所以怎么处理空值显得特别重要,不合理的设计很容易造成app的闪退。

    从后台的角度来说,api中返回的数据中,正确值和空值的类型必须一样,举例,用户名的字段是“realname": "xxx”,如果用户名为空,则应该返回“realname": ""。如果返回值是一个array,空数据则返回一个空array,绝对禁止null值。

    对于客户端,必须用个全局的函数来处理所有api的返回数据,需要有一个机制:对于某个客户端需要数据,如果api中缺失,客户端自动补上并给予默认值。这个机制在我们的实践中大大减少了app的闪退。

    同时,在数据库设计的时候,一个合理的设计必须是所有字段都有默认值,不应该允许null值。null在大量的语言和数据库中,会带来无穷的问题。对于这个数据库设计原则,我以前不太明白,现在经历了一年的api设计后,终于懂得。

    如果客户端是php,还有一个问题,php中数组和字典都是array,但在java 和object-c中是不一样,这个问题一定要注意。

 

(5)图片的处理

 

    在不同版本的app中,各种不同尺寸的手机中,同一张图片显示的尺寸可能是不一样,如果每次都需要用返回原图,然后在客户端处理,则极大浪费网络资源。而如果是后台处理好图片才返回,则又是一个挑战,怎么有效保存和裁剪多种图片尺寸呢

    例如,一开始头像只需要返回60*60的尺寸,后来在新的版本需要返回70*70, 又出了一个新版本,需要返回80*80, 每次增加一个新的尺寸,怎么在数据库上记录下来。这个问题在一开始做api的时候没考虑,后来不得不用了一个极端的方法,没增加新的图片尺寸,就在数据库中增加一个新的字段,保存并生成新的图片尺寸,结果最后数据库的头像字段有"avatar","avatar_60_60","avatar_70_70","avatar_80_80",这种极度恶虐的设计。

    最后,针对图片,我们才用了这样的策略:

(1)客户端本地缓存图片,只有没有合适的图片,才去服务器取。

(2)当客户端需要某种尺寸的图片,由客户端告诉服务端图片的尺寸,服务端动态生成并缓存起来。

 

     例如,客户端需要图片(http://www.baidu.com/img/bdlogo.gif)的80*80的尺寸,则在图片的路径加上宽和高的参数(类似于CDN的机制) http://www.baidu.com/img/bdlogo.gif?w=80&h=80, 则服务器就生成80*80的尺寸并返回。

 

    采用了这样的图片处理机制,数据库中只要有一个字段保存原图就行了,其它尺寸就由客户端告诉服务端动态生成。以后无论什么尺寸的图片,数据库中都不需要记录,数据库只有原图就行了。

 

(6)返回的提示信息

   最科学的情况,服务端只返回信息代码,具体的文字提示由客户端决定。

    如果文字信息是由服务端返回,则最起码要区分2种信息:提示用户的信息,提示客户端程序员的信息。这两者的区别:

1.提示用户的信息是要在让客户知道的,提示客户端程序员的信息不需要让客户知道的。

2. 提示用户的信息文字很友好,客户不需要专业基础一看就知道是什么,提示客户端程序员的信息则很专业,例如告诉客户端少传了哪个参数?哪个参数有问题等等。

 

(7)在线api文档和测试

 

    我们网站的api在线测试文档,既是一份在线api文档,也是一个在线测试工具,极大方便沟通和测试。每次客户端程序员觉得某个api有什么问题,我们就是这个在线工具上讨论沟通的。客户端程序员最喜欢这个玩意了^-^。

    上个图解一下馋(这个图是旧版的api,已经弃用了):



负责做这个功能的同事专门写了篇博客详细介绍了这个在线api测试文档,还带有demo:

 

 http://amuropikin.iteye.com/blog/1701537

 

 

app后端系列文章总目录

 

 

///////////////////////////////////////////////////////

2014.01.31: 扩展了app的通讯安全性的讨论 

 

 

[文章作者]曾健生

[作者邮箱][email protected]

[作者QQ]190678908

[新浪微博] @newjueqi

[博客] http://blog.csdn.net/newjueqi

http://blog.sina.com.cn/h6k65

你可能感兴趣的:(转载,app服务端)