RESTful规范建议

RESTful概述

RESTful是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便,因此正获得愈来愈多网站的采用。json

REST是Representational State Transfer的缩写,是Roy Thomas Fielding在他2000年的博士论文中提出的。其提出的设计概念和准则为:api

1. 网络上的全部事物均可以抽象为资源缓存

2. 每一个资源都应该有惟一的标识(identifier),对资源的操做不会改变标识安全

3. 全部的操做都是无状态的服务器

4. 使用标准方法(GET、POST、PUT、PATCH、DELETE)操做资源网络

 

RESTful使用

HTTP方法 URI 描述 幂等 安全
 GET  /api/members  获取成员列表  是  是
 GET  /api/members/{id}   获取指定成员  是  是
 POST  /api/members  建立一个成员  否  否
 PUT  /api/members/{id}   更新成员全部信息  是  否
 PATCH  /api/members/{id}   更新成员部分信息  是  否
 DELETE  /api/members/{id}   删除指定成员  是  否
HTTP方法 URI 描述 幂等 安全
 GET  /api/groups  获取群组列表  是  是
 GET  /api/groups/{id}  获取指定群组  是  是
 POST  /api/groups  建立一个群组  否  否
 PUT  /api/groups/{id}  更新群组全部信息  是  否
 PATCH  /api/groups/{id}  更新群组部分信息  是  否
 DELETE  /api/groups/{id}  删除指定群组  是  否
 GET  /api/groups/{id}/members  获取指定群组下的成员  是  是
 GET  /api/groups/{id}/members/{memberId}  获取指定群组下的指定成员  是   是

幂等性:同一个RESTful接口的屡次访问,获得的资源状态是相同的。架构

安全性:对该RESTful接口访问,不会使服务端资源的状态发生改变。app

 

规范建议

1. API尽可能采用经过安全通道的HTTPS协议(https)。dom

  

2. 请求体与响应体统一经过json格式来承载,json使用Camel的命名规则,媒体类型需设置为“application/json”。ide

示例:

Request

  Accept: application/json

  Content-Type: application/json

 

Response

  Content-Type: application/json

 

3. 请求体与响应体统一采用UTF-8编码格式,时间统一使用UTC格式:yyyy-MM-dd'T'HH:mm:ss[.SSS]'Z'。

 

4. URI模版:/{domain}/{service or module}/api/{version}/{resource},URI应全为小写字母,短语单词使用“-”分隔。

名称 说明 示例
 domain  领域名称,不须要区分领域时,能够不指定

 education(教育领域)

 finance(金融领域)

 game(游戏领域)

 service or module  服务或模块名

 account(帐户模块)

 order(订单服务)

 storage(库存服务)

 version  版本号

 v1

 v2

 v3

 resource  服务或模块内资源

 users(用户)

 products(产品)

 members(成员)

 

5. 资源增、删、改、查外的操做,采用模板:/{domain}/{service or module}/api/{version}/{resource}/action/{action}。

示例:/common/account/api/v1/users/action/login

 

响应消息建议

1. 获取资源列表成功返回200,响应消息体中包含记录总条数、当前页码、每页记录,以及对应的资源。

示例:

Response Body

{

  "total": xxx,

  "pageIndex": xxx,

  "pageSize":xxx,

  "records":[

    { "id": xxx, "name":"xxx" },

    { "id": xxx, "name":"xxx" }

  ]

}

 

2. 获取指定资源成功返回200,响应消息体中包含该资源的信息。

 

3. 建立资源成功返回201,并在响应消息头中包含定位该资源的地址。

示例:

Response Headers

{
  "pragma": "no-cache",
  "server": "xxx",
  "content-type": "application/json; charset=utf-8",
  "location": "https://xxx/api/users/xxx", //资源访问地址
  "content-length": "xxx"
}

 

4. 资源更新成功返回200,并在响应消息中体返回更新后的资源内容。

 

5. 资源删除成功返回204,响应消息体无内容。

 

6. 针对400 Bad Request客户端错误,能够在响应消息体中扩展状态码。

示例:

Response Code

400 Bad Request

Response Body

{

  "code": 400001,

  "message": "用户名或密码错误"

}

 

----------------------------------------------------------

Response Code

400 Bad Request

Response Body

{

  "code": 400002,

  "message": "邮箱已存在"

}

 

----------------------------------------------------------

Response Code

400 Bad Request

Response Body

{

  "code": 400003,

  "message": "邮箱地址错误"

}

 

7. 针对5XX的服务端错误,只在响应消息体中提供简单提示,不可打印错误日志信息。

示例:

Response Body

{

  "message": "内部错误,请稍后再试或联系管理员"

}

 

7. 其余客户端错误的响应码,只在响应消息体中提供相应提示。

示例:

Response Code

401 Unauthorized

Response Body

{

  "message": "用户未登陆"

}

 

----------------------------------------------------------

Response Code

403 Forbidden

Response Body

{

  "message": "权限不足"

}

 

----------------------------------------------------------

Response Code

404 Not Found

Response Body

{

  "message": "请求资源不存在或已被删除"

}

 

常见响应码

响应码 说明
 200 OK  请求已成功
 201 Created  资源已建立
 204 No Content  请求已成功,但无返回内容
 304 Not Modified  缓存有效
 400 Bad Request  语义有误,当前请求没法被服务器理解,请求参数错误
 401 Unauthorized  当前请求须要用户认证(登陆)
 403 Forbidden  用户已认证(登陆),但权限不足
 404 Not Found  请求源未在服务器上被发现
 405 Method Not Allowed  请求方法不能被用于请求相应的资源,如使用PUT方法访问只接受POST方法的API
 500 Internal Server Error  服务端内部错误
 502 Bad Gateway  网关错误
 504 Gateway Timeout  网关超时
相关文章
相关标签/搜索