什么是API测试？

API测试利用编程向API发送调用并获得产量。它的测试将被测段视为一个黑盒子。API测试的目的是在将部件协调到应用程序之前确认部件的正确执行和错误处理。

休息API

REST：代表性状态转移。

这是测试人员执行请求和接收响应的功能安排。在REST API中，通过HTTP协议进行交互。REST还允许计算机之间通过网络相互通信。对于发送和接收消息，它涉及使用HTTP方法，并且不像Web服务那样需要严格的消息定义。REST消息通常接受XML或JavaScript对象符号（JSON）形式的表单。

4常用API方法：-

GET：–它提供对资源的只读访问。POST：–用于创建或更新新资源。PUT：–用于更新或替换现有资源或创建新资源。DELETE：–用于删除资源。

手动测试API的步骤：-

要手动使用API，我们可以使用基于浏览器的REST API插件。

安装POSTMAN（Chrome）/REST（Firefox）插件输入API URL选择REST方法选择内容标题输入请求JSON（POST）单击发送它将返回输出响应

自动化REST API的步骤

如果我不得不将关于REST的原始论文缩减为短短的3句话，我认为以下内容抓住了它的精髓：

通过URL请求资源。协议仅限于使用URL进行通信的内容。元数据作为名称-值对（发布数据和查询字符串参数）传递。

之后，很容易陷入关于适应、编码约定和最佳实践的争论。

有趣的是，本文中没有提到HTTPPOST、GET、DELETE或PUT操作。这一定是后来有人对“统一界面”的“最佳实践”的解释。

当涉及到web服务时，我们似乎需要一些方法来区分WSDL和基于SOAP的体系结构，这会给接口增加相当大的开销和不必要的复杂性。它们还需要额外的框架和开发人员工具才能实现。我不确定REST是否是区分常识接口和过度工程化接口（如WSDL和SOAP）的最佳术语。但我们需要一些东西。

这是一个令人惊讶的漫长的“讨论”，但至少可以说相当令人困惑。

IMO:

1） 没有一个大的酒吧和大量的啤酒，就没有一个安静的程序：）

2） 代表性状态转移（REST）是罗伊·菲尔丁（Roy Fielding）论文中提出的一种体系结构风格。它有许多限制。如果您的服务/客户尊重这些，那么它就是RESTful。就这样。

您可以（显著地）总结以下约束：

无状态通信遵守HTTP规范（如果使用HTTP）清晰传达传输的内容格式使用超媒体作为应用程序状态引擎

还有一个很好的帖子很好地解释了事情。

许多答案复制/粘贴了有效的信息，混淆了这些信息，增加了一些混乱。人们在这里谈论级别、RESTFulURI（没有这样的东西！）、应用HTTP方法GET、POST、PUT。。。REST不是关于这个或者不仅仅是关于这个。

例如，链接-有一个漂亮的API是很好的，但最终客户端/服务器并不真正关心你获得/发送的链接，重要的是内容。

最终，只要内容格式已知，任何RESTful客户端都应该能够使用任何RESTful服务。

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通常是如何实现的，而不是它的真正含义。我修改了答案，以更好地代表真正的含义。）

RESTful（代表性状态转移）API编程是通过以下5个基本的软件架构风格原则，以任何编程语言编写web应用程序：

资源（数据、信息）。唯一的全局标识符（所有资源都由URI标识）。统一接口-使用简单标准接口（HTTP）。表示-所有通信都是通过表示（例如XML/JSON）完成的无状态（每个请求都是在完全隔离的情况下发生的，这样更容易缓存和负载平衡），

换句话说，您正在通过HTTP编写简单的点对点网络应用程序，该应用程序通过实现RESTful架构使用GET、POST、PUT或DELETE等动词，该架构提出了每个“资源”公开的接口的标准化。以一种简单有效的方式（高度成功、经过验证和分布式架构）使用web的当前特性并不重要。它是SOAP、CORBA和RPC等更复杂机制的替代方案。

RESTful编程符合Web体系结构设计，如果实现得当，它允许您充分利用可扩展的Web基础设施。

一种称为REST（RepresentationalStateTransfer）的体系结构风格主张web应用程序应该像最初设想的那样使用HTTP。查找应使用GET请求。PUT、POST和DELETE请求应分别用于变异、创建和删除。

REST支持者倾向于使用URL，例如

http://myserver.com/catalog/item/1729

但REST架构不需要这些“漂亮的URL”。带有参数的GET请求

http://myserver.com/catalog?item=1729

完全是RESTful的。

请记住，GET请求不应用于更新信息。例如，向购物车添加项目的GET请求

http://myserver.com/addToCart?cart=314159&item=1729

这是不合适的。GET请求应该是幂等的。也就是说，发出两次请求与发出一次请求应该没有区别。这就是请求可缓存的原因。一个“添加到购物车”请求不是幂等的，发出两次请求会向购物车添加两个项目副本。POST请求显然适合于这种情况。因此，即使是RESTful web应用程序也需要共享POST请求。

这摘自大卫·M·Geary的优秀著作《核心JavaServer面孔》。