RESTful编程到底是什么?
当前回答
老问题,新的回答方式。关于这个概念有很多误解。我总是努力记住:
结构化URL和Http方法/动词不是restful编程。JSON不是restful编程RESTful编程不适用于API
我将restful编程定义为
如果应用程序以客户端理解的媒体类型提供资源(是数据+状态转换控件的组合),则该应用程序是静止的
要成为一个安静的程序员,您必须尝试构建允许参与者做事的应用程序。不仅仅是公开数据库。
只有当客户端和服务器同意资源的媒体类型表示时,状态转换控制才有意义。否则,无法知道什么是控件,什么不是控件,以及如何执行控件。IE如果浏览器不知道html中的<form>标签,那么在浏览器中就没有什么可以提交到过渡状态。
我不想自我推销,但我在演讲中深入阐述了这些想法http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .
我演讲中的一段摘录是关于经常提到的richardson成熟度模型,我不相信这些级别,你要么是RESTful(级别3),要么不是,但我想指出的是,在你走向RESTful的过程中,每个级别都为你做了什么
其他回答
我想说,理解REST的一个重要组成部分在于端点或映射,例如/customers/{id}/balance。
您可以将这样的端点想象为从网站(前端)到数据库/服务器(后端)的连接管道。使用它们,前端可以执行在应用程序中任何REST映射的相应方法中定义的后端操作。
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。
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通常是如何实现的,而不是它的真正含义。我修改了答案,以更好地代表真正的含义。)
这在任何地方都很少被提及,但Richardson的成熟度模型是实际判断Restful是API的最佳方法之一。更多信息请点击此处:
理查德森成熟度模型
老问题,新的回答方式。关于这个概念有很多误解。我总是努力记住:
结构化URL和Http方法/动词不是restful编程。JSON不是restful编程RESTful编程不适用于API
我将restful编程定义为
如果应用程序以客户端理解的媒体类型提供资源(是数据+状态转换控件的组合),则该应用程序是静止的
要成为一个安静的程序员,您必须尝试构建允许参与者做事的应用程序。不仅仅是公开数据库。
只有当客户端和服务器同意资源的媒体类型表示时,状态转换控制才有意义。否则,无法知道什么是控件,什么不是控件,以及如何执行控件。IE如果浏览器不知道html中的<form>标签,那么在浏览器中就没有什么可以提交到过渡状态。
我不想自我推销,但我在演讲中深入阐述了这些想法http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .
我演讲中的一段摘录是关于经常提到的richardson成熟度模型,我不相信这些级别,你要么是RESTful(级别3),要么不是,但我想指出的是,在你走向RESTful的过程中,每个级别都为你做了什么
推荐文章
- 有没有REST api的命名规范指南?
- 由Jon Skeet撰写的《Singleton》澄清
- 什么是HTTP中的“406-不可接受的响应”?
- 最好的轻量级web服务器(只有静态内容)的Windows
- HTTP POST在Java中使用JSON
- 哪些HTTP方法与哪些CRUD方法相匹配?
- 使用HTML形式的PUT方法
- 如何转义哈希字符在URL
- RESTful服务中部分更新的最佳实践
- JAX-RS / Jersey如何自定义错误处理?
- 有没有办法在python中做HTTP PUT
- 我能在服务器端应用程序(PHP、Ruby、Python等)上读取URL的哈希部分吗?
- 如何POST表单数据与Spring RestTemplate?
- 什么是http头“X-XSS-Protection”?
- 在nodejs http中body在哪里。得到回应?