关于架构:架构之REST和RESTful

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

REST 是一种架构。

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

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

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

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

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

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

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

在 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 的资源链接。

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

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

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

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

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

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

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

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

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

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

咱们来举几个常见的 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/

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

关于架构:架构之REST和RESTful

简介

REST

REST 和 RESTful API

REST 架构的根本准则

Uniform interface 对立的接口

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

Stateless 无状态

Cacheable 可缓存

Layered system 分层零碎

Code on demand 按需编码

RESTful API 的例子

总结