RESTful编程到底是什么?
当前回答
这就是它可能看起来的样子。
创建具有三个财产的用户:
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
其他回答
什么是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的步骤
我看到了一堆回答,说将用户123的所有内容放在资源“/user/123”是RESTful的。
罗伊·菲尔丁(Roy Fielding)创造了这个术语,他表示RESTAPI必须是超文本驱动的。特别是,“REST API不能定义固定的资源名称或层次结构”。
因此,如果您的“/user/123”路径在客户端上被硬编码,那么它就不是真正的RESTful。很好地使用HTTP,也许,也许不是。但不是RESTful。它必须来自超文本。
剩下的一点是,如果我们同意对基本操作使用通用语言(http动词),那么可以配置基础结构来理解它们并适当地优化它们,例如,通过使用缓存头在所有级别实现缓存。
通过正确实现的restful GET操作,信息来自服务器的DB、服务器的memcache、CDN、代理的缓存、浏览器的缓存或浏览器的本地存储都无关紧要。可以使用最快、最容易获得的最新来源。
说Rest只是语法上的改变,从使用带有动作参数的GET请求到使用可用的http动词,这看起来没有任何好处,而且纯粹是修饰。重点是使用一种可以被链的每个部分理解和优化的语言。如果GET操作有副作用,则必须跳过所有HTTP缓存,否则结果将不一致。
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通常是如何实现的,而不是它的真正含义。我修改了答案,以更好地代表真正的含义。)
如果我没有直接回答这个问题,我很抱歉,但通过更详细的例子更容易理解这一切。由于所有的抽象和术语,字段化并不容易理解。
这里有一个很好的例子:
解释REST和超文本:垃圾邮件清理机器人Spam-E
更棒的是,这里有一个简单的例子(powerpoint更全面,但你可以在html版本中获得大部分内容):
http://www.xfront.com/REST.ppt或http://www.xfront.com/REST.html
看完这些例子后,我明白了Ken为什么说REST是超文本驱动的。但我实际上并不确定他是对的,因为/user/123是指向资源的URI,我不清楚它是否是非RESTful的,因为客户端知道它是“带外”的
xfront文档解释了REST和SOAP之间的区别,这也非常有用。当Fielding说:“这是RPC。它尖叫RPC。”时,很明显RPC不是RESTful的,所以了解这一点的确切原因很有用。(SOAP是RPC的一种类型。)
推荐文章
- 有没有办法在python中做HTTP PUT
- 我能在服务器端应用程序(PHP、Ruby、Python等)上读取URL的哈希部分吗?
- 如何POST表单数据与Spring RestTemplate?
- 什么是http头“X-XSS-Protection”?
- 在nodejs http中body在哪里。得到回应?
- BASE术语解释
- Restful API服务
- Ruby:如何将散列转换为HTTP参数?
- 在用nodejs和express创建的REST API中设置响应状态和JSON内容的正确方法
- 如何POST JSON数据与PHP卷曲?
- HTTP 1.1和HTTP 2.0的区别是什么?
- REST身份验证方案的安全性
- 如何在package.json中使用“main”参数?
- 什么是“升级-不安全-请求”HTTP报头?
- HTTP 301和308状态码有什么区别?