概念：
REST (REpresentational State Transfort) 字面上表述为客户端通过申请资源来实现状态的转换。REST应该满足这样的特点：
1)客户端和服务器结构；
2)连接协议具有无状态性；
3)能够利用Cache机制增进性能；
4)统一接口；
5)层次化的系统；
RESTful API ：
符合REST设计风格的Web API称为RESTful API。它从以下三个方面资源进行定义：
- 直观简短的资源地址：URI。原来uri包括url和urn，后来urn没流行起来，导致几乎目前所有的uri都是url。uri中不应该包含动词。资源表示的一种实体，应该都是名词。只能用HTTP请求方法表示资源操作动作。例如/posts/show/1 应该改为/posts/1 用GET方法表明是show操作。
- 传输的资源：Web服务接受与返回的互联网媒体类型，比如：JSON，XML，YAML等。
- 对资源的操作：Web服务在该资源上所支持的一系列请求方法，比如：POST，GET，PUT或DELETE。
无状态性
按照REST的要求，Restful API的URL地址应指向具体的一个资源，例如用户 user 。URL 中应当只包含资源名词，不应该包含指向操作的动词，例如新建、查询、修改、删除等。具体操作通过 HTTP 动词（ GET / POST / PUT / DELETE ）指定。
// 传统的 RPC 形式
https://open.domain.com/app/getUser
// 按照 Restful API 的设计，HTTP GET 请求
https://open.domain.com/app/user
指定参数
//URL 地址参数
https://open.domain.com/app/user/123456/Admin
// ? 参数
https://open.domain.com/app/user?id=123456&type=Admin
安全认证机制
在使用 Restful API ，特别是对公网开放的 Restful API，通常需要通过一定的安全认证机制来进行实现访问控制。目前主流的方案是通过 OAuth2.0 实现安全认证。
提供对外的 API 时，应当尽可能的使用 HTTPS 协议，以确保传输过程的安全。
比较：
优势：Restful API 充分利用了 HTTP 协议的设计，使用面向资源的接口设计（无状态），相对于传统 RPC 降低了接口设计的复杂度。
劣势：对于复杂的需求，比如“下单”这一功能，它涉及到了订单、用户、支付账户等多个资源实体的多种操作，很难将该业务归类为 HTTP 动词中的某一种。难以设计为 Restful API 。
使用场景：资源集中型服务，例如针对用户的信息查询，针对订单的信息查询的等，这类型服务以资源实体为中心，操作大多为简单的 CRUD 操作，业务逻辑简单。
例子：
package com.ibm.jaxrs.sample.organization;
import java.util.List;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
@Path(value="/contacts")
public class ContactsResource {
@GET
public List<ContactInfo> getContactss() {
...
}
@GET
@Path(value="/ids")
public List<String> getContactIds() {
...//发送到 /contacts/ids路径的 HTTP GET 请求将会由 getContactIds()
}
@Path(value="/contact/{contactName}/department")
//@Produces生产 写出到response的内容类型
@Produces(value={"text/xml", "application/json"})
//@Consumes消费 是接收客户端传过来的内容类型
@Consumes(value={"text/xml", "application/json"})
public Department getContactDepartment(@PathParam(value="contactName")
String contactName) {
...
}
}
要点：无状态性。Restful API的URL地址不应该包含指向操作的动词。具体操作通过 HTTP 动词（ GET / POST / PUT / DELETE ）指定。
