Restful API的设计思路

API的就是程序员的UI，和其他UI一样，你必须仔细考虑它的用户体验！
Restful只是web api/Json传输接口通过http调，取到还要自己解。Rpc一般都是配套的，客户端直接像调本地函数一样调用(一般用在内网服务间调用，可以用rpc的框架thrift）
Swagger可以用来管理你的RESTful API

使用SSL(https)来提供URL

• 使用https可以在数据包被抓取时多一层加密

• 即使你使用了https，黑客抓不到你具体传输的数据，但是可以抓到你请求的URL啊！因此，使用https进行请求时，要采用POST、PUT或者HEAD的方式传输必要的数据

使用GET、POST、PUT、DELETE这几种请求模式

• curl请求支持这些请求方式

• get（select）从服务器抽取资源；

• post（create）在服务器创建一个资源；

• put（update）在服务器更新资源；

• delete（delete）从服务器删除资源。

在URI中体现资源，而非动作

• 每个网址代表一种资源，不能用动词只能有名词，多用复数名词

• URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联

• 使用?用来过滤资源，很多人只是把?简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。？对应的是一些特定条件的查询结果或算法运算结果。

• ,或;可以用来表示同级资源的关系，有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。

版本

• 接口参数或返回值有变化

• 逻辑处理有变化

HTTP响应码

下面是一些参考的状态码：

• 200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。

• 201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。

• 202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）

• 204 NO CONTENT - [DELETE]：用户删除数据成功。

• 400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。

• 401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。

• 403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。

• 404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。

• 406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。

• 410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。

• 422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。

• 500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。

返回值结构

使用JSON进行返回：

• JSON可以很好的被很多程序支持，javascript的ajax可以直接将JSON转换为对象。

• JSON的格式在容量上比xml小很多，可以减低宽带占用，提高传输效率。

• 字段的合理返回，数据的包裹。因为返回值中，我们常常要对数据进行区分分组，或者按照从属关系打包，所以，我们再返回时，最好有包裹的思想，把数据存放在不同的包裹中进行返回。

      {
          "error_code" : ,
          "data" : {
               "user_id" : ,
               "username" : "admin"
           },
          "server_time": 14939939
      }
  

鉴权

• 通行的是使用OAuth的方式，通过AccessToken来进行身份管理

自我保护能力

• 即使使用的人没仔细看API文档随便乱用也不会导致系统出问题，这种案例非常的多，例如对外提供了一个批量查询接口，结果用户一下传了一个里面有上千个用户id的数组，查询一下直接把内存耗光，像这种情况下不能怪使用的人，而应该怪实现API的这一端的保护做的不够好，按照这样的标准去看，会发现开源的很多东西的API都不太合格；