架构之:REST和RESTful

川长思鸟来 2023-01-23 12:56 34阅读 0赞

### 文章目录 ###

*  简介
 *  REST
 *  REST和RESTful API
 *  REST架构的基本原则
 *   *  Uniform interface统一的接口
     *  Client–server 客户端和服务器端独立
     *  Stateless无状态
     *  Cacheable可缓存
     *  Layered system分层系统
     *  Code on demand按需编码
     *  RESTful API的例子
 *  总结

# 简介 #

近几年微服务是如火如荼的在发展，而微服务之间的调用和渐渐的从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/][http_www.flydean.com_01-rest-restful]
> 
> 最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！

[http_www.flydean.com_01-rest-restful]: http://www.flydean.com/01-rest-restful/