Web项目开发模式 和 Restful接口设计风格

Web项目开发模式
本小节学习目标：

理解前后端不分离和前后端分离两种开发模式的特点
了解web项目两种开发模式的优缺点
web项目开发的两种模式
在Web项目开发中，有两种开发模式：

前后端不分离
前后端分离

1. 前后端不分离
   特点：前端看到的效果都是由后端控制的，后端通过渲染之后给前端返回完整的html页面，前端与后端的耦合度很高。

前后端不分离

2. 前后端分离
   特点：后端仅返回前端所需的数据，至于数据怎么进行展示，由前端自己进行控制，前端与后端的耦合度很低。

前后端分离

小知识：什么是API？

答：API(Application Programming Interface)，中文译为：应用程序编程接口。本课程中，在前后端分离开发模式中，我们通常将后端开发的视图中的每个处理方法都称为一个接口或者API。

3. 开发模式对比
   模式区别：

前后端不分离：完整的页面是在后端生成的，后端给前端返回完整的页面，前端只是进行展示。
前后端分离：完整的页面是在前端生成的，后端只给前端返回所需的数据，前端将数据填充在页面上。
优缺点：

开发模式 优点 缺点
前后端不分离 利于SEO(搜索引擎优化) 仅适合于纯网页的应用
前后端分离 可以对接不同类型的客户端 不利于SEO(搜索引擎优化)
小知识：什么是SEO？

答：SEO(Search Engine Optimization)，中文译为：搜索引擎优化。是针对搜索引擎排名的一种优化手段，其主要目的是希望用户在通过搜索引擎搜索某个关键字时，自己的网站在搜索结果中的排名能够相对靠前。搜索引擎优化的一个基础点，就是通过返回给客户端的页面内容上多加对应的关键字来提高搜索引擎排名。前后端分离开发模式中，后端给前端返回的数据，是前端浏览器通过js填充到页面上的。目前各家搜索引擎，对于js填充数据的抓取支持并没有那么好，会导致搜索引擎不能分析网页的主体内容，不利于SEO的优化。

小结：

前后端不分离：前端看到的效果是由后端控制的，后端模板渲染返回给客户端完整的页面。
前后端分离：后台只返回前端所需的数据，至于数据怎么展示，由前端自己进行控制。
前后端不分离适合于纯网页的应用，前后端分离可以对接不同类型的客户端。

RESTful接口设计风格
本小节学习目标：

理解RestAPI接口设计风格的关键要点
了解RestAPI接口设计风格的其他内容
RestAPI接口设计风格
在进行API接口设计时，不同的开发人员可能有着不同的设计风格，风格迥异。那是否存在一种统一的接口设计方式，被广大开发人员所接受呢？

答：这就是被普遍采用的RESTful API设计风格。Restful API设计风格给接口设计人员提供了各种建议，目前在企业项目的接口设计中，大家普遍都会根据Restful风格的建议来进行API接口的设计。

1. Restful风格设计-关键要点
   要点1：URL路径
   URL地址尽量使用名词复数，不要使用动词。

例如：

不好的例子：url中含有动词

/getProducts
/listOrders

正确的例子：地址使用名词复数

GET /products：将返回所有产品信息
POST /products：将新建产品信息
GET /products/4：将获取产品4
PUT /products/4：将更新产品4
路径又称"终点"（endpoint），表示API的具体网址，每个网址代表一种资源（resource）。

要点2：请求方式
访问同一个URL地址，采用不同的请求方式，代表要执行不同的操作。

常用的HTTP请求方式有如下四种：

请求方式 说明
GET 获取资源数据(单个或多个)
POST 新增资源数据
PUT 修改资源数据
DELETE 删除资源数据
例如：

GET /books：获取所有图书数据
POST /books：新建一本图书数据
GET /books//：获取某个指定的图书数据
PUT /books//：更新某个指定的图书数据
DELETE /books//：删除某个指定的图书数据
要点3：过滤信息
过滤参数可以放在查询字符串中进行传递。

在访问API接口获取数据时，可能需要对数据进行过滤。

比如一些常见的参数：

?limit=10：指定返回记录的数量。
?offset=10：指定返回记录的开始位置。
?page=2&pagesize=100：指定第几页，以及每页的记录数。
?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
要点4：响应数据
针对不同操作，服务器向用户返回不同的响应数据。

一般遵循以下规范：

1. 获取一组数据，返回一组数据
2. 获取指定数据，返回指定数据
3. 新增数据，返回新增的数据
4. 修改数据，返回修改的数据
5. 删除数据，返回空
   要点5：响应数据格式
   服务器返回的响应数据格式，应该尽量使用JSON。

要点6：响应状态码
服务器向客户端返回的状态码和提示信息，常见的状态码如下：

200 OK - [GET/PUT]：服务器成功返回用户请求的数据。
201 CREATED - [POST]：用户新建数据成功。
204 NO CONTENT - [DELETE]：用户删除数据成功。
400 INVALID REQUEST - [POST/PUT]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作。
404 NOT FOUND - []：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。
500 INTERNAL SERVER ERROR - []：服务器发生错误，用户将无法判断发出的请求是否成功。
状态码的完全列表参见这里或这里。

要点7：错误响应信息
如果状态码是4xx，服务器就应该向用户返回出错信息。

如：

{
error: “”
}
2. Restful风格设计-其他
其他1：域名
应该尽量将API部署在专用域名之下。

https://api.example.com
如果确定API很简单，不会有进一步扩展，可以考虑放在主域名下。

https://www.example.com/api/
其他2：版本
应该将API的版本号放入URL。

http://www.example.com/api/1.0/foo

http://www.example.com/api/1.1/foo

http://www.example.com/api/2.0/foo
另一种做法是，将版本号放在HTTP头信息中，但不如放入URL方便和直观。Github采用这种做法。

其他3：超媒体
RESTful API最好做到Hypermedia（即返回结果中提供链接，指向其他API方法），使得用户不查文档，也知道下一步应该做什么。

比如，Github的API就是这种设计，访问api.github.com会得到一个所有可用API的网址列表。

{
“current_user_url”: “https://api.github.com/user”,
“authorizations_url”: “https://api.github.com/authorizations”,
…
}
从上面可以看到，如果想获取当前用户的信息，应该去访问api.github.com/user，然后就得到了下面结果。

{
“message”: “Requires authentication”,
“documentation_url”: “https://developer.github.com/v3”
}
上面代码表示，服务器给出了提示信息，以及文档的网址。

总结：

要点
url地址 url地址尽量使用名词复数，不要使用动词
请求方式 执行不同的操作，采用不同的请求方式：
GET(获取)
POST(新增)
PUT(修改)
DELETE(删除)
过滤参数 过滤参数放在查询字符串中
响应数据 获取多个数据时，返回对应的多个数据
获取单个数据时，返回对应的单个数据
新增数据时，将新增的数据返回
修改数据时，将修改的数据返回
删除数据时，返回空
响应数据格式 JSON
响应状态码 200(获取或修改成功)
201(新增成功)
204(删除成功)
404(资源找不到)
500(服务器出错)
响应错误信息 如果出错，服务器应该向客户端返回相应的出错信息