简介

近几年微服务是热火朝天的在倒退，而微服务之间的调用和慢慢的从 RPC 调用转移到了 HTTP 调用。于是常常听到有些共事说咱们提供微服务并且裸露 RESTful 接口给别的零碎，然而什么是 RESTful 接口呢？它和 REST 有什么关系呢？
别急，本文将会带你一探到底。

REST

REST 是一种架构。

首先咱们要记住的是 REST 是一种架构形式，并不是一种协定。它只是通知咱们应该如何去搭建一个牢靠的零碎。

REST 的全称是 REpresentational State Transfer。中文可能不好翻译，咱们暂将其定义为有代表性的状态本义。它是分布式系统的一种架构形式。最先是由 Roy Fielding 在 2000 年他的博士毕业论文中首先提到的。

REST 架构在当初的 web 利用中十分常见，它并不波及到具体的编码，它只是一种高级比的领导计划，具体的实现还是由你本人决定。

REST 和 RESTful API

咱们刚刚解说了 REST，那么 REST 和 RESTful API 有什么关系呢？

咱们晓得，API 是服务和服务之间，客户端和服务端之间沟通的桥梁，通过 API 之间的调用，咱们能够从服务器中获取到须要的资源信息。而 RESTful API 就是合乎 REST 架构的 API。

所以不是所有的 HTTP 协定的 API 都是 RESTful API，它的前提是你的零碎是 REST 架构的。

REST 架构的根本准则

那么什么样的零碎能力被称为是 REST 架构的零碎呢？依据 Roy Fielding 的论文形容，REST 架构的零碎有 6 个基本特征。咱们一一来阐明。

Uniform interface 对立的接口

在 REST 架构中，最为外围的元素就是资源。咱们将资源定义为一个个的独立的 URI。一个资源用一个独立并且惟一的 URI 来示意。

单个的资源不能太大也不能太小，它示意的是一个独立的能够操作的单位。这些资源通过通用的获取形式来进行获取和操作。比方对资源的 CURD 能够别离用不同的 HTTP method 来示意（PUT，POST，GET，DELETE）。

同时须要对资源进行对立的命名，定义对立的 link 格局和数据格式。

还有一点，依据 HATEOAS 协定，一个资源还应该蕴含指向该资源或者相干资源的 URI。能够能有些同学当初对这一点还有些纳闷，不过没关系，前面咱们会具体对 HATEOAS 进行解说。

Spring 也提供了对 HATEOAS 的反对，咱们看一个根本的 HATEOAS 的申请：

GET http://localhost:8080/greeting

该申请的返回能够是这样的：

{
  "content":"Hello, World!",
  "_links":{
    "self":{"href":"http://localhost:8080/greeting?name=World"}
  }
}

大家能够看到下面返回了一个代表本人 URI 的资源链接。

Client–server 客户端和服务器端独立

另外的一条规定就是客户端和服务器端独立，客户端和服务器端互不影响，他们之间的惟一交互就是 API 的调用。

对于客户端来说只有可能通过 API 获取到对应的资源即可，并不关怀服务器是怎么实现的。

而对于服务器端来说，只须要提供放弃不变的 API 即可，本人外部的实现能够自在决定，也不须要思考客户端是如何应用这些 API 的。

这条规定对于当初的很多前后端拆散的架构来说曾经应用了。

Stateless 无状态

和 HTTP 协定一样，REST 架构中各个服务之间的 API 调用也是无状态的。无状态的意思是服务器并不保留 API 调用的历史记录，也不存储任何对于客户端的信息。对于服务器来说，每个申请都是最新的。

所以用户的状态信息是在客户端进行保留和保护的，客户端须要在每个接口带上能够辨认用户的惟一标记，从而在服务器端进行认证和辨认，从而获取到对应的资源。

Cacheable 可缓存

缓存是晋升零碎速度的利器，对于 REST 的资源也是一样的，在 REST 中对于可缓存的资源须要表明它是能够被缓存的。

从而对应的调用方能够将这些资源进行缓存，从而晋升零碎的效率。

Layered system 分层零碎

古代的零碎基本上都是分层的，在 REST 架构中也是一样，只有保障对外提供的资源 URI 是统一的，架构并不关怀你到底应用的是几层架构。

Code on demand 按需编码

一般来说，REST 架构中各个服务通常是通过 JSON 或者 XML 来进行交互的。然而这并不是硬性规定。能够返回可执行的代码间接运行。

RESTful API 的例子

咱们来举几个常见的 RESTful API 的例子，来见识一下这种架构的神奇之处：

申请一个 entity：

GET https://services.odata.org/TripPinRESTierService/People

依据 ID 申请一个 entity:

GET https://services.odata.org/TripPinRESTierService/People('russellwhyte')

申请一个 entity 的某个属性：

GET https://services.odata.org/TripPinRESTierService/Airports('KSFO')/Name

应用 filter 进行查问：

GET https://services.odata.org/TripPinRESTierService/People?$filter=FirstName eq 'Scott'

批改数据：

POST https://services.odata.org/TripPinRESTierService/People
header:
{Content-Type: application/json}
body:
{
    "UserName":"lewisblack",
    "FirstName":"Lewis",
    "LastName":"Black",
    "Emails":["lewisblack@example.com"],
    "AddressInfo": [
    {
      "Address": "187 Suffolk Ln.",
      "City": {
        "Name": "Boise",
        "CountryRegion": "United States",
        "Region": "ID"
      }
    }
    ]
}

删除数据：

DELETE https://services.odata.org/TripPinRESTierService/People('russellwhyte')

更新数据：

PATCH https://services.odata.org/TripPinRESTierService/People('russellwhyte')
header:
{Content-Type: application/json}
body:
{
    "FirstName": "Mirs",
    "LastName": "King"
}

总结

本文解说了 REST 和 RESTful 相干的概念，那么对于其中最重要的资源如何定义呢？敬请期待后续文章。

本文已收录于 http://www.flydean.com/01-rest-restful/

最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！