您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
移动互联网实战--Web Restful API设计和基础架构
 
  2616  次浏览      14
 2018-6-22 
 
编辑推荐:

本文来自于cnblogs,本文主要讲述主流的几种, 并对web server的基础架构做个简单的描述。

前言:

在移动互联网的大潮中, 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协议之上, 两者的状态不该绑定, 至于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反向代理的结合

  

   
2616 次浏览       14
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践