发表于： 2018-01-30 22:59:42

今日完成：

1. 幂等：任意多次执行所产生的影响均与一次执行的影响相同。

2. REST表述性状态传递(英文:Representational State Transfer,简称REST)：描述了HTTP层里客户端和服务器端的数据交互规则；客户端通过向服务器端发送HTTP（s）请求，接收服务器的响应，完成一次 HTTP 交互。

REST其实是一种组织Web服务的架构，其目标是为了创建具有良好扩展性的分布式系统

a) 使用客户/服务器模型。客户和服务器之间通过一个统一的接口来互相通讯。

b) 层次化的系统。在一个REST系统中，客户端并不会固定地与一个服务器打交道。

c) 无状态。在一个REST系统中，服务端并不会保存有关客户的任何状态。也就是说，客户端自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。

d) 可缓存。REST系统需要能够恰当地缓存请求，以尽量减少服务端和客户端之间的信息传输，以提高性能。

e) 统一的接口。一个REST系统需要使用一个统一的接口来完成子系统之间以及服务与用户之间的交互。这使得REST系统中的各个子系统可以独自完成演化。

i. 每个资源都拥有一个资源标识。每个资源的资源标识可以用来唯一地标明该资源。

ii. 消息的自描述性。在REST系统中所传递的消息需要能够提供自身如何被处理的足够信息。例如该消息所使用的MIME类型，是否可以被缓存等。

iii. 资源的自描述性。一个REST系统所返回的资源需要能够描述自身，并提供足够的用于操作该资源的信息，如如何对资源进行添加，删除以及修改等操作。也就是说，一个典型的REST服务不需要额外的文档对如何操作资源进行说明。

iv. HATEOAS。即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如到底是向哪个URL发送请求等。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作。一个REST服务的客户端也不需要知道任何有关哪里有什么样的资源这种信息

前后向兼容性以及进行版本管理

准确地使用HTTP协议

Content-Type: application/json 按照JSON的格式理解或分析该响应中的负载（消息的自描述性）

hot_searches 热搜关键词

在表示单个资源的时候，URL常常会包含着资源在该类资源中的ID

URL和ID：URL用来指向资源所在的地址，而ID则表示该资源在该类型资源中的ID

以资源为中心的描述方法：这种描述方法的确有别于很多Web服务那样以动作为中心。而与之对应的则是系统设计步骤的改变：我们将不再首先是别完成业务逻辑所需的各动作，而是支持业务逻辑所需要的各资源。首先，我们对某个操作不要再关注它所执行的动作，而是关心它所操作的宾语。通常情况下，该宾语就会是REST系统中的资源。

例如对于登陆这一行为，其实际上在服务端创建了一个会话实例。该会话实例中则包含了登陆IP，登陆时间，以及登陆时所用的凭证等。再比如对于用户更改密码这种行为，其所操作的资源就是用户资料。

在抽象资源的过程中，我们需要按照自顶向下的方式，即首先辨识出系统中的最主要资源，然后再辨识这些主要资源的子资源，并依次进行迭代。

对主资源的抽取主要通过分析业务逻辑来完成。在得到功能需求以后，我们首先要分析这些业务逻辑所操作的宾语。这些宾语可能有两种情况：主资源或者其它资源的子资源。主资源实际上就是能够独立存在的一系列资源。而子资源则需要依附于主资源之上才能表达实际的意义。同时各个子资源也可能拥有自身的子资源。

如果一个资源是主资源，那么其可以被不同的资源实例包含引用而不会产生歧义。而如果一个资源是子资源，那么被不同的资源实例引用可能会产生歧义。

如何判断我们为REST服务所定义的资源是否合理

首先，我们需要考虑对该资源的CRUD是否有意义；从而验证资源的定义是否合理。

其次，我们需要检查资源是否需要除CRUD之外的动词来操作；检查资源中是否还有子资源没有被抽象

我们还需要检查这些资源是否是被整体使用，创建和删除；探测是否一个子资源应该是一个主资源

在HTTP中，一个URL主要由以下几个部分组成：

a) 协议。即HTTP以及HTTPS。

b) 主机名和端口。如www.egoods.com:8421

c) 资源的相对路径。如/api/categories。

d) 请求参数。即由问号开始的由键值对组成的字符串：?page=1&page_size=20

在为一个资源设计其所对应的URL时，我们需要着重考虑第三部分和第四部分组成。

通过URL来表示资源：

所有的资源都应该存在于一个相对路径之下：

从向该相对路径发送请求才能得到的各个主资源来说，将它们置于相对路径/api之下是非常合理的

API的版本更迭也是一个考虑。假如软件开发人员需要开发一个新版本的REST API，那么他可能就需要重新抽象并定义系统中的各个资源。但是如果两个版本的API中都拥有一个categories资源，并且系统为了保持后向兼容性同时保留了两个版本的API，那么将只有一个资源可以使用/categories这个相对路径。也正因为如此，将这些资源置于相对路径/api之下，并在第二个版本的API出现之后将新的资源抽象置于/api-v2下是一种较为流行的做法。

使用HTTP来构建REST系统，那么我们就需要遵守URL各组成中的含义：URL中的相对路径将用来标示“What I want”，也既对应着资源；而请求参数则用来标示“How I want”，即查看资源的方式。

请求API的URL表示用来定位资源:

1. URL 中不应该出现任何表示操作的动词，链接只用于对应资源；

2. URL 中应该单复数区分，推荐的实践是永远只用复数；比如 GET /api/users 表示获取用户的列表；如果获取单个资源，传入 ID，比如 /api/users/123 表示获取单个用户的信息；

3. 按照资源的逻辑层级，对 URL 进行嵌套，比如一个用户属于某个团队，而这个团队也是众多团队之一；

"/"不应该出现在URL的末尾；

那么获取这个用户的接口可能是这样:

GET /api/teams/123/members/234 表示获取 id 为 123 的小组下，id 为234 的成员信息

请求的METHOD表示对这个资源进行的操作:

【Read】资源的读取，用 GET 请求；GET /api/users （表示读取用户列表）；安全，不产生副作用

【Created】资源的创建，用 POST 方法；非幂等；

【Update】资源的更新。用于更新的 HTTP 方法有两个，PUT （更新全部信息）和 PATCH（更新局部信息）；幂等；

PUT和POST两者都有创建的含义，但是意义却不同。

如果希望客户端在创建资源的时候显式地指定该资源的ID，那么就需要使用PUT。而在由服务端为该资源自动赋予ID的时候，我们就需要在创建资源时使用POST。

Ps：PATCH 的作用在于如果一个资源有很多字段，在进行局部更新时，只需要传入需要修改的字段即可。否则在用 PUT 的情况下，你不得不将整个资源模型全都发送回服务器，造成网络资源的极大浪费。

【Delete】，资源的删除，相应的请求 HTTP 方法就是 DELETE；幂等；

不常用：HEAD：获取资源的元数据。

OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

3. MVC是一种经典的设计模式，全名为Model-View-Controller，即模型-视图-控制器。

其中，模型是用于封装数据的载体，例如，在Java中一般通过一个简单的POJO（Plain Ordinary Java Object）来表示，其本质是一个普通的Java Bean，包含一系列的成员变量及其getter/setter方法。对于视图而言，它更加偏重于展现，也就是说，视图决定了界面到底长什么样子，在Java中可通过JSP来充当视图，或者通过纯HTML的方式进行展现，而后者才是目前的主流。模型和视图需要通过控制器来进行粘合，例如，用户发送一个HTTP请求，此时该请求首先会进入控制器，然后控制器去获取数据并将其封装为模型，最后将模型传递到视图中进行展现。