REST是web的基础架构原则。web的惊人之处在于，客户端（浏览器）和服务器可以以复杂的方式交互，而客户端事先不知道服务器及其托管的资源。关键的限制是服务器和客户端都必须对所使用的媒体达成一致，在web的情况下，媒体是HTML。

遵循REST原则的API不要求客户端了解API的结构。相反，服务器需要提供客户端与服务交互所需的任何信息。HTML表单就是这样的一个例子：服务器指定资源的位置和所需的字段。浏览器事先不知道在哪里提交信息，也不知道要提交什么信息。这两种形式的信息完全由服务器提供。（这一原则被称为HATEOAS：作为应用程序状态引擎的超媒体。）

那么，这如何适用于HTTP，如何在实践中实现呢？HTTP以动词和资源为导向。主流用法中的两个动词是GET和POST，我想每个人都会认识到。然而，HTTP标准定义了其他几个，如PUT和DELETE。然后根据服务器提供的指令将这些动词应用于资源。

例如，假设我们有一个由web服务管理的用户数据库。我们的服务使用一个基于JSON的自定义超媒体，为此我们分配了mimetype application/JSON+userdb（也可能有application/xml+userdb和application/whatever+userdb-可能支持许多媒体类型）。客户机和服务器都经过编程，可以理解这种格式，但他们对彼此一无所知。正如罗伊·菲尔丁指出的：

REST API应该在定义用于表示资源和驱动的媒体类型应用程序状态，或定义扩展关系名称和/或现有标准媒体类型的超文本标记。

对基本资源/的请求可能会返回如下内容：

要求

GET /
Accept: application/json+userdb

回答

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

我们从媒体的描述中知道，我们可以从“链接”部分找到有关相关资源的信息。这称为超媒体控件。在这种情况下，我们可以从这样一个部分看出，通过对/user发出另一个请求，我们可以找到一个用户列表：

要求

GET /user
Accept: application/json+userdb

回答

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

从这一反应中我们可以看出很多。例如，我们现在知道可以通过向/user发帖来创建新用户：

要求

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

回答

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

我们还知道，我们可以更改现有数据：

要求

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

回答

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

请注意，我们使用不同的HTTP动词（GET、PUT、POST、DELETE等）来操纵这些资源，并且我们假设客户端的唯一知识是我们的媒体定义。

进一步阅读：

这一页上有很多更好的答案。我如何向妻子解释REST。我如何向妻子解释REST。马丁·福勒的思想PayPal的API具有超媒体控制

（这个答案因为没有抓住重点而受到了相当多的批评。在大多数情况下，这是一个公平的批评。我最初描述的内容更符合几年前我第一次写这篇文章时REST通常是如何实现的，而不是它的真正含义。我修改了答案，以更好地代表真正的含义。）

这就是它可能看起来的样子。

创建具有三个财产的用户：

POST /user
fname=John&lname=Doe&age=25

服务器响应：

200 OK
Location: /user/123

以后，您可以检索用户信息：

GET /user/123

服务器响应：

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

要修改记录（姓名和年龄将保持不变）：

PATCH /user/123
fname=Johnny

要更新记录（因此lname和age将为NULL）：

PUT /user/123
fname=Johnny

一本关于REST的好书是《实践中的REST》。

必须读取代表性状态传输（REST），并且REST API必须是超文本驱动的

有关RESTful服务的解释，请参见Martin Fowlers的文章《Richardson成熟度模型》（RMM）。

要实现RESTful，服务需要实现作为应用程序状态引擎的超媒体。（HATEOAS），也就是说，它需要达到RMM中的3级，阅读文章以了解详细信息或qcon演讲中的幻灯片。

HATEOAS约束是首字母缩略词超级媒体的引擎应用程序状态。这一原则是REST之间的关键区别以及大多数其他形式的客户端服务器系统...RESTful应用程序的客户端需要只知道要访问的单个固定URL所有未来的行动都应该可从中动态发现超媒体链接包含在资源的表示从该URL返回。标准化媒体类型也是预期任何人都能理解可能使用RESTful API的客户端。（来自免费百科全书维基百科）

Web框架的REST Litmus测试是Web框架的类似成熟度测试。

接近纯REST：学会爱HATEOAS是一个很好的链接集合。

针对公共云的REST与SOAP讨论了REST使用的当前级别。

REST和版本控制讨论了可扩展性、版本控制、可演化性等。通过可修改性

REST使用各种HTTP方法（主要是GET/PUT/DELETE）来处理数据。

您不需要使用特定的URL来删除方法（例如/user/123/delete），而是向/user/[id]URL发送delete请求，以编辑用户，检索有关向/user/[id]发送GET请求的用户的信息

例如，取而代之的是一组URL，可能看起来像下面的一些。。

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

您使用HTTP“动词”并具有。。

GET /user/2
DELETE /user/2
PUT /user

为了在这里贡献一些新的东西，我想分享我文章中的链接，即通过一种实用和客观的方法将REST概念化。

我将介绍以下主要概念：

HATEOAS-超媒体作为应用程序状态的引擎，资源和表示，可寻址性，REST中的幂等性，Richardson的REST成熟度模型。媒体类型API版本控制

我还创建了一个GitHub项目，您可以使用docker轻松运行，它涵盖了我在本文中介绍的内容。

https://itnext.io/how-to-build-a-restful-api-a-deep-dive-into-rest-apis-215188f80854

Edit

阅读这里的自述文件，我希望你真的能得到REST。

https://github.com/lukepuplett/surfdude-csharp/blob/master/README.md

--

这些给出链接资源示例的答案很好，但只占一半。

所以，想象你正在设计一个网站。你写一个故事，

我希望能够通过邮政编码搜索地址，以便选择发货地址

然后，您将构建网站，让用户踏上旅程，并尝试在工作流中将页面链接在一起。

一个网站设计让他们进行地址查找，然后让他们将地址复制到剪贴板，然后返回到发货地址表单，这是不太有用的。

REST API使用我们在web上认为理所当然的模式进行机器-机器交互。

对邮政编码功能的搜索不应该是base/addresss/{postcode}，并且会返回一个集合，即使每个地址都链接到一个完整的地址和一些编辑链接，因为这是一个死胡同；API使用者需要猜测如何使用该地址。

相反，该功能的动机应内置于其使用的流程中，以便旅程在开始时结束：

1 GET /orders/123/shipping

  200 OK { Current shipping details + link to parent + link to address picker }

2  -> GET /orders/123/shipping/addresspicker

      200 OK { Link and form for searching for a postcode }

3   -> GET /orders/123/shipping/addresspicker?postcode=tn11tl

       200 OK { List of addresses each with link to pick it }

4    -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3

        200 OK { Current shipping details + link to parent + link to address picker }

这是一次用户旅程，最后您可以看到流量对订单的影响。

HTTP请求/响应严格来说不是REST的一部分，但我认为没有人见过非HTTP REST应用程序。

现在这些URL可以是任何一组字符，它们只是标识符，我把它们做得很漂亮，因为它们对人们来说很有意义。机器将使用rel来计算它们做什么，而不依赖于可读的href。