移动互联网实战--Web Restful API设计和基础架构
前言:
在移动互联网的大潮中, Web Restful API逐渐成为Web Server重要的一个分支. 移动端和服务端的交互, 主流的方式还是通过Http协议的形式来进行. 请求以Get/Post方式, 响应以json(数据更小巧且自描述能力强)的方式占据主流. 各大互联网公司, 对自身的Web Api设计有各自的标准. 本文主要讲述主流的几种, 并对web server的基础架构做个简单的描述.
百度云实现方案:
百度移动云事业部的对云服务的Web Api借鉴了亚马逊的AWS实现方案. 具体可参见百度移动云开发者网站: http://developer.baidu.com/.
该Restful API的设计特点, 主要由以下几方面来描述.
1). URL的设计
http[s]://{server}/rest/2.0/{product}/{resource}?{query_string}
server: 具体服务的域名
product: 具体服务的产品名称
resource: 具体服务的某个资源名称
query_string: 具体服务的某个方法所有key/value对参数(包括函数名)
2). 请求/响应数据格式
基于HTTP协议, 支持GET/POST两种方式, 一般读请求采用GET模式, 而写请求采用POST的模式.
请求数据格式: 与普通的web服务并无区别, GET模式参数搁置在query_string中, POST模式参数搁置在POST附带参数中
响应数据格式: 响应的结果和业务服务相关
#) 业务操作成功
{
"request_id":12394838223,
"response_params": { ... }
}
评注: request_id是本次请求的标识号, 用于问题查找, response_params则包含了具体业务的响应结果.
#) 业务操作失败
{
"request_id":12394838223,
"error_code":30000,
"error_msg":"Request params not valid"
}
评注: 失败返回的结果固定包含三部分: request_id/error_code/error_msg, error_code指定错误码, error_msg为具体的出错信息.
3). 业务逻辑状态与http响应码的绑定
业务结果与http响应码的绑定, 不管是否合理, 这也算是AWS Web API的一大特色.
比如:
| http状态码 | 业务错误码 | 业务错误描述信息 | 业务错误描述信息 |
| 200 | |||
| 404 | 30605 | Data Required Not Found | 请求数据不存在 |
| 500 | 30600 | Internal Server Error | 服务器内部错误 |
评注: 业务服务层应该在http协议之上, 两者的状态不该绑定, 至于AWS为何这样设计, 我只能说"存在即合理"
该方案实战和点评:
世上没有一个方案是完美的, 它总有它的不足存在. 这边谈谈小编在工程实践中, 对此方案所感慨的一些不足.
在某个具体的云服务应用中, 特定的一个方法访问成为了热点(其他方法访问量少). 我们想在反向代理层(lighttpd/nginx)作分流, 让实现FastCGI的C模块代替原生的PHP CGI. Web Server是依据URI中的服务域名和URI PATH来匹配划分/分流, 然而遗憾的是method方法参数在URI的query_string中, 该方案无法实施. 如果method参数在URI中的PATH中那就好办了.
尽管HTTP协议属于网络的应用层, 但是再细分的话, 业务层该在HTTP协议之上, 不同的协议层, 彼此之间应该互不影响. 业务错误码和http状态码的绑定多少让人有些困惑. 有些发生在Web Server层的真正404错误, 却被Web API的Client SDK误认为了业务逻辑错误, 这些其实不应该发生.
个人比较推崇的做法:
1). Http的请求分为URL约定规则、请求参数规则
URL规则:
http://{server}/{product}/{version}/{logic}/{method}?{query_string}
server: 为具体的服务域名
product: 为应用工程名
version: 为具体版本号, 便于将来的功能扩展, 可以暂定为 1.0, 2.0
logic: 为具体业务逻辑的初步划分, 比如后端管理方法, app端的请求方法
method: 具体业务的方法
具体的请求参数, 由指定的method方法决定, 全都作为HTTP GET/POST的参数列表.
2). Http的响应规则
HTTP响应码为200, 逻辑结果以JSON字符串的形式组织:
如果响应结果正确,则返回结果如下所示:
{
"success": true,
"result_value" : {
/* 由具体的业务方法决定 */
}
}
如果响应结果失败,则返回如下结果:
{
"success": false,
"request_id": 10001,
"err_code": 1001,
"err_msg": "Internal Server Error"
}
借鉴了AWS的设计思路, 同时抛弃了业务错误码与HTTP状态码的绑定, 同时把method/logic/version搁置在URI中的PATH中, 便于WebServer的分流.
Web Server的基础架构
对于Web Server的基础架构, 大致有以下几种流行的方式.
1). 采用LVS的方式:
对内部多个节点(IP地址)的访问, 对外抽象为同一个IP地址, 这就是LVS的方式. 其可以理解为软件级负载均衡方式(需要依赖硬件)
2). 采用Nginx/Apache的反向代理:
评注:Nginx的反向代理,可以方便对静态资源和动态资源做分离, 对小企业而言, 是最常用的一种方式.
3). LVS和Nginx/Apache反向代理的结合
注: 图片来自网络.