REST（Representational State Transfer）架构风格是一种广泛使用的网络架构，它定义了一组核心概念，包括传输、状态、表示、安全性和幂等性。本文将探讨这些核心概念如何映射到HTTP协议中，并分析HTTP协议在实现RESTful通信时的局限性。
REST的核心概念可以概括为传输、状态、表示、安全性和幂等性。在HTTP协议中，这些概念可以通过以下方式实现：
HTTP协议要求请求-响应通信模型，通过引入动词来区分请求数据和提供数据的请求。这些动词包括GET和PUT（或POST）。HTTP协议可以携带任何数据，因此应用程序可以自由构建它们的表示。
GET /music HTTP/1.1
Host: example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 123
{"song": "Hotel California", "artist": "Eagles"}
以上代码示例展示了如何使用HTTP协议传输音乐播放器的状态。
在实际应用中，状态修补技术是优化的关键，因为状态通常是庞大的。HTTP使用URI来唯一标识状态块，称之为“资源”。
GET /resource/123 HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 123
{"id": 123, "value": "some data"}
PUT /resource/123 HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 123
{"id": 123, "value": "updated data"}
以上代码示例展示了如何使用URI读取和写入状态块（资源）。
在事务性读取多个状态块（资源）时，需要在单个自包含的消息中请求所有资源，然后由服务器在另一个自包含的消息中发送。这只有在可以构建一个包含所有请求资源的URL时才可能。
HTTP协议本身不支持在单个GET请求中包含多个URI。同样，对于响应消息，也没有在单个HTTP响应消息中发送多个资源及其URI的方法。
POST /resources HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 123
["/resource/1", "/resource/2", "/resource/3"]
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 123
[{"id": 1, "value": "data1"}, {"id": 2, "value": "data2"}, {"id": 3, "value": "data3"}]
以上代码示例展示了如何使用POST请求和一些非标准的解决方案来实现事务性读取。
PUT /resource/123 HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 123
{"id": 123, "value": "new data"}
DELETE /resource/123 HTTP/1.1
Host: example.com
以上代码示例展示了如何使用PUT和DELETE动词来修补可变状态。
HTTP协议是一个优秀的协议，它很好地服务于其目的。它催生了REST，并受到了REST的影响，但它并不是100%的RESTful（实际上，它是一个可以在其基础上构建RESTful行为的RPC）。人们已经尝试通过设计巧妙的URI和表示来解决这些不足，但最终，纯粹的100%标准HTTP不能提供真正的RESTful通信，除非每次传输“整个”状态。
一个真正覆盖所有示例用例的RESTful协议可以使用任何它认为合适的传输方式，但应定义消息如下：