RESTful浅析

一、RESTful

它是一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件，它不是一门新的技术。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

1. REST描述的是在网络中client和server的一种交互形式；REST本身不实用，实用的是如何设计 RESTful API（REST风格的网络接口）；
2. Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。比如：
http://api.qc.com/v1/newsfeed: 获取某人的新鲜; 
http://api.qc.com/v1/friends: 获取某人的好友列表;
http://api.qc.com/v1/profile: 获取某人的详细信息;

3. 用HTTP协议里的动词来实现资源的添加，修改，删除等操作。即通过HTTP动词来实现资源的状态扭转：
GET 用来获取资源，
POST 用来新建资源（也可以用于更新资源），
PUT 用来更新资源，
DELETE 用来删除资源。比如：
DELETE http://api.qc.com/v1/friends: 删除某人的好友 （在http parameter指定好友id）
POST http://api.qc.com/v1/friends: 添加好友
UPDATE http://api.qc.com/v1/profile: 更新个人资料

4. Server和Client之间传递某资源的一个表现形式，比如用JSON，XML传输文本，或者用JPG，WebP传输图片等。当然还可以压缩HTTP传输时的数据（on-wire data compression）。
5. 用 HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误等。

主要信息就这么点。最后是要解放思想，Web端不再用之前典型的PHP或JSP架构，而是改为前段渲染和附带处理简单的商务逻辑（比如AngularJS或者BackBone的一些样例）。Web端和Server只使用上述定义的API来传递数据和改变数据状态。格式一般是JSON。iOS和Android同理可得。由此可见，Web，iOS，Android和第三方开发者变为平等的角色通过一套API来共同消费Server提供的服务。

REST -- REpresentational State Transfer
全称是 Resource Representational State Transfer：通俗来讲就是：资源在网络中以某种表现形式进行状态转移。分解开来：
Resource：资源，即数据（前面说过网络的核心）。比如 newsfeed，friends等；
Representational：某种表现形式，比如用JSON，XML，JPEG等；
State Transfer：状态变化。通过HTTP动词实现。

二、首先为什么要用RESTful结构呢？

        大家都知道"古代"网页是前端后端融在一起的，比如之前的PHP，JSP等。在之前的桌面时代问题不大，但是近年来移动互联网的发展，各种类型的Client层出不穷，RESTful可以通过一套统一的接口为 Web，iOS和Android提供服务。另外对于广大平台来说，比如Facebook platform，微博开放平台，微信公共平台等，它们不需要有显式的前端，只需要一套提供服务的接口，于是RESTful更是它们最好的选择。在RESTful架构下：

三、Server的API如何设计才满足RESTful要求?

1. URL root:
https://example.org/api/v1/*
https://api.example.com/v1/*2. API versioning:
可以放在URL里面，也可以用HTTP的header：
/api/v1/
3. URI使用名词而不是动词，且推荐用复数。
BAD

· /getProducts

· /listOrders

· /retrieveClientByOrder?orderId=1

GOOD

· GET /products : will return the list of all products

· POST /products : will add a product to the collection

· GET /products/4 : will retrieve product #4

· PATCH/PUT /products/4 : will update product #4

4. 保证 HEAD 和 GET 方法是安全的，不会对资源状态有所改变（污染）。比如严格杜绝如下情况：
GET /deleteProduct?id=1
5. 资源的地址推荐用嵌套结构。比如：
GET /friends/10375923/profile
UPDATE /profile/primaryAddress/city6. 警惕返回结果的大小。如果过大，及时进行分页（pagination）或者加入限制（limit）。HTTP协议支持分页（Pagination）操作，在Header中使用 Link 即可。
7. 使用正确的HTTP Status Code表示访问状态：HTTP/1.1: Status Code Definitions
8. 在返回结果用明确易懂的文本（String。注意返回的错误是要给人看的，避免用 1001 这种错误信息），而且适当地加入注释。
9. 关于安全：自己的接口就用https，加上一个key做一次hash放在最后即可。考虑到国情，HTTPS在无线网络里不稳定，可以使用Application Level的加密手段把整个HTTP的payload加密。有兴趣的朋友可以用手机连上电脑的共享Wi-Fi，然后用Charles监听微信的网络请求（发照片或者刷朋友圈）。
如果是平台的API，可以用成熟但是复杂的OAuth2，

RESTful一句简单的描述：URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。

四、RESTful的关键

        RESTful的关键是定义可表示流程元素/资源的对象。在REST中，每一个对象都是通过URL来表示的，对象用户负责将状态信息打包进每一条消息内，以便对象的处理总是无状态的。

        RESTful的第二大问题是组合管理及流程绑定。企业对正规的（基于SOAP）SOA最大的反对声之一便是，这种等级的发现和绑定灵活性不足以适应复杂性。
实用的是如何正确地理解 RESTful架构和设计好RESTful API。

常用的HTTP动词有下面五个（括号里是对应的SQL命令）。

§ GET（SELECT）：从服务器取出资源（一项或多项）。

§ POST（CREATE）：在服务器新建一个资源。

§ PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。

§ PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。

§ DELETE（DELETE）：从服务器删除资源。

过滤信息

§ ?limit=10：指定返回记录的数量

§ ?offset=10：指定返回记录的开始位置。

§ ?page=2&per_page=100：指定第几页，以及每页的记录数。

§ ?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。

§ ?animal_type_id=1：指定筛选条件

GET /animals?zoo_id=ID 

返回结果

针对不同操作，服务器向用户返回的结果应该符合以下规范。

§ GET /collection：返回资源对象的列表（数组）

§ GET /collection/resource：返回单个资源对象

§ POST /collection：返回新生成的资源对象

§ PUT /collection/resource：返回完整的资源对象

§ PATCH /collection/resource：返回完整的资源对象

§ DELETE /collection/resource：返回一个空文档

 

下面是一些例子。

§ GET /zoos：列出所有动物园

§ POST /zoos：新建一个动物园

§ GET /zoos/ID：获取某个指定动物园的信息

§ PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）

§ PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）

§ DELETE /zoos/ID：删除某个动物园

§ GET /zoos/ID/animals：列出某个指定动物园的所有动物

§ DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

 

 

 

链接：https://www.zhihu.com/question/28557115/answer/48094438