RESTful编程究竟是什么?
一种名为REST (Representational State Transfer)的架构风格提倡Web应用程序应该像最初设想的那样使用HTTP。查找应使用GET
请求。 PUT
, POST
, and DELETE
requests应分别用于变异,创建和删除。
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请求应该是idempotent。也就是说,发出两次请求应该与发出一次请求没有什么不同。这就是使请求可缓存的原因。 “添加到购物车”请求不是幂等的 - 发布它两次将该项目的两个副本添加到购物车。在这种情况下,POST请求显然是合适的。因此,即使是RESTful Web应用程序也需要它的POST请求份额。
这取自David M. Geary的优秀书籍Core JavaServer面子书。
如果我没有直接回答这个问题,我会道歉,但通过更详细的例子更容易理解这一切。由于所有的抽象和术语,Fielding不容易理解。
这里有一个相当不错的例子:
Explaining REST and Hypertext: Spam-E the Spam Cleaning Robot
更好的是,这里有一个简单的例子清晰的解释(powerpoint更全面,但你可以在html版本中获得大部分内容):
http://www.xfront.com/REST.ppt或http://www.xfront.com/REST.html
阅读完示例后,我可以看出为什么Ken说REST是超文本驱动的。我不确定他是对的,因为/ user / 123是一个指向资源的URI,并且我不清楚它是不是因为客户端“带外”知道它是不可靠的。
该xfront文档解释了REST和SOAP之间的区别,这也非常有用。当Fielding说“That is RPC. It screams RPC.”时,很明显RPC不是RESTful,因此查看确切原因很有用。 (SOAP是一种RPC。)
什么是REST?
REST官方话说,REST是一种基于某些原则的架构风格,使用当前的“Web”基础。 Web有5个基本基础,可用于创建REST服务。
我看到一堆答案,说将用户123的所有内容放在资源“/ user / 123”上是RESTful。
创造这个词的罗伊菲尔丁说,REST APIs must be hypertext-driven。特别是,“REST API不能定义固定资源名称或层次结构”。
因此,如果您的“/ user / 123”路径在客户端上是硬编码的,那么它并不是真正的RESTful。很好地利用HTTP,也许不是。但不是RESTful。它必须来自超文本。
答案非常简单,有一个由Roy Fielding编写的dissertation。] 1在那篇论文中,他定义了REST原则。如果应用程序满足所有这些原则,那么这就是REST应用程序。
The term RESTful was created because ppl exhausted the word REST by calling their non-REST application as REST.之后,RESTful这个词也用尽了。 Nowadays we are talking about Web APIs and Hypermedia APIs,因为大多数所谓的REST应用程序都没有满足统一接口约束的HATEOAS部分。
REST约束如下:
POST https://example.com/api/v1/order
消息。之后,服务处理消息并使用具有正确HTTP状态标头的结果进行响应,例如201 - created
成功。要使用详细元数据注释消息,使用RDF格式的标准解决方案,例如带有REST词汇的JSON-LD,例如Hydra和域特定词汇,如schema.org或任何其他linked data vocab,如果需要,可能是自定义应用程序特定词汇。现在这并不容易,这就是为什么大多数人使用HAL和其他简单格式的原因,这些格式通常只提供REST词汇,但没有链接数据支持。REST约束导致高度可扩展的系统,其中客户端与服务的实现分离。因此,客户端可以重复使用,就像网络上的浏览器一样。客户端和服务共享相同的标准和词汇,因此尽管客户端不知道服务的实现细节,但他们可以相互理解。这使得创建自动化客户端成为可能,这些客户端可以找到并利用REST服务来实现其目标。从长远来看,这些客户可以相互沟通,相互信任,就像人类一样。如果我们向这样的客户端添加学习模式,那么结果将是使用机器网而不是单个服务器园的一个或多个AI。所以最后伯纳斯李的梦想:语义网和人工智能将成为现实。所以在2030年我们终于被天网终止了。直到那时 ... ;-)
RESTful(Representational state transfer)API编程通过以下5个基本软件architectural style原则编写任何编程语言的Web应用程序:
换句话说,您正在通过HTTP编写简单的点对点网络应用程序,它通过实现RESTful架构来使用诸如GET,POST,PUT或DELETE之类的动词,该架构提出了每个“资源”公开的接口的标准化。以简单有效的方式使用Web的当前功能(非常成功,经过验证和分布式架构)并不是什么。它是SOAP,CORBA和RPC等更复杂机制的替代品。
RESTful编程符合Web架构设计,如果实施得当,它可以让您充分利用可扩展的Web基础架构。
如果我不得不将关于REST的原始论文减少到只有3个短句,我认为以下内容抓住了它的本质:
在那之后,很容易陷入有关改编,编码惯例和最佳实践的争论中。
有趣的是,论文中没有提到HTTP POST,GET,DELETE或PUT操作。这必须是某人后来对“统一界面”的“最佳实践”的解释。
当谈到Web服务时,似乎我们需要一些区分WSDL和基于SOAP的体系结构的方法,这会增加相当大的开销,并且可能会给接口带来很多不必要的复杂性。他们还需要额外的框架和开发人员工具才能实现。我不确定REST是否是区分常识接口和过度设计的接口(如WSDL和SOAP)的最佳术语。但我们需要一些东西。
REST是一种编写分布式应用程序的架构模式和风格。从狭义上讲,它不是一种编程风格。
说你使用REST风格类似于说你建造了一个特定风格的房子:例如Tudor或Victorian。作为软件风格的REST和作为家庭风格的都铎王朝或维多利亚时代都可以通过构成它们的品质和约束来定义。例如,REST必须具有客户端服务器分离,其中消息是自描述的。都铎风格的住宅拥有重叠的山墙和屋顶,与前面的山墙陡峭搭配。您可以阅读Roy的论文,以了解构成REST的约束和质量的更多信息。
与家庭风格不同的REST在一直和实际应用中遇到了困难。这可能是故意的。将其实际实施留给设计师。因此,只要您满足创建REST系统论文中规定的约束条件,您就可以自由地执行所需的操作。
奖金:
整个Web基于REST(或REST基于Web)。因此,作为Web开发人员,您可能需要注意这一点,尽管没有必要编写好的Web应用程序。
这是我的REST基本概要。我试图展示RESTful架构中每个组件背后的思想,以便更直观地理解这个概念。希望这有助于为某些人揭开REST的神秘面纱!
REST(Representational State Transfer)是一种设计体系结构,概述了如何设计和寻址网络资源(即共享信息的节点)。通常,RESTful架构使得客户端(请求机器)和服务器(响应机器)可以请求读取,写入和更新数据,而客户端不必知道服务器如何操作以及服务器可以通过它不需要知道客户端的任何信息。好的,很酷......但是我们如何在实践中做到这一点?
但REST架构并没有就此结束!虽然上述内容满足了我们想要的基本需求,但我们还希望拥有一个支持高流量流量的体系结构,因为任何给定的服务器通常都会处理来自多个客户端的响应。因此,我们不希望通过记住有关先前请求的信息来压倒服务器。
现在,如果所有这些听起来都很熟悉,那么很棒。通过万维网定义通信协议的超文本传输协议(HTTP)是RESTful架构的抽象概念的实现(如果你是像我这样的OOP狂热者,则是REST类的一个实例)。在REST的这个实现中,客户端和服务器通过GET,POST,PUT,DELETE等进行交互,这些是通用语言的一部分,并且可以使用URL指向资源。
我认为,在利用互联网(协议)作为无状态传输层的同时,将有状态分离为更高层是重要的。大多数其他方法混合起来。
这是处理互联网时代编程根本变化的最佳实用方法。关于根本性的变化,Erik Meijer在这里有一个讨论:http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197。他将其总结为五种效果,并通过将解决方案设计为编程语言来提供解决方案。无论语言如何,解决方案也可以在平台或系统级别实现。宁静可以被视为在当前实践中非常成功的解决方案之一。
通过宁静的风格,您可以在不可靠的互联网上获取和操纵应用程序的状态。如果当前操作未能获得正确的当前状态,则需要零验证主体来帮助应用程序继续。如果它无法操纵状态,它通常会使用多个阶段的确认来保持正确。从这个意义上讲,休息本身并不是一个完整的解决方案,它需要Web应用程序堆栈其他部分的功能来支持其工作。
鉴于这一观点,其余的风格并没有真正与互联网或网络应用程序联系在一起。它是许多编程情况的基本解决方案。它也不简单,它只是使界面非常简单,并且非常好地应对其他技术。
只是我的2c。
编辑:两个更重要的方面:
这是非常长的“讨论”,但至少可以说是相当混乱。
IMO:
1)没有宁静的编程,没有大关节和大量的啤酒:)
2)Representational State Transfer(REST)是the dissertation of Roy Fielding中指定的架构风格。它有许多限制。如果您的服务/客户尊重这些,那么它就是RESTful。就是这个。
您可以(显着地)将约束汇总到:
还有另一个very good post很好地解释了事情。
许多答案复制/粘贴有效信息混合它并添加一些混淆。人们在这里谈论层次,关于RESTFul URI(没有这样的东西!),应用HTTP方法GET,POST,PUT ...... REST不仅仅是关于那个问题。
例如链接 - 拥有一个漂亮的API很好,但最后客户端/服务器并不真正关心你获得/发送的链接是重要的内容。
最后,只要内容格式已知,任何RESTful客户端都应该能够使用任何RESTful服务。
REST是Web的基础架构原则。关于Web的惊人之处在于,客户端(浏览器)和服务器可以以复杂的方式进行交互,而客户端无需事先了解服务器及其承载的资源。关键的限制是服务器和客户端必须同意所使用的媒体,在网络的情况下是HTML。
遵循REST原则的API不要求客户端了解有关API结构的任何信息。相反,服务器需要提供客户端与服务交互所需的任何信息。 HTML表单就是一个例子:服务器指定资源的位置和必填字段。浏览器事先不知道提交信息的位置,并且事先不知道要提交哪些信息。两种形式的信息完全由服务器提供。 (这个原则叫做HATEOAS: Hypermedia As The Engine Of Application State。)
那么,这如何应用于HTTP,以及如何在实践中实现? HTTP围绕动词和资源。主流使用的两个动词是GET
和POST
,我想每个人都会认出来。但是,HTTP标准定义了其他几个,例如PUT
和DELETE
。然后根据服务器提供的指令将这些动词应用于资源。
例如,假设我们有一个由Web服务管理的用户数据库。我们的服务使用基于JSON的自定义超媒体,我们为其分配了mimetype application/json+userdb
(可能还有application/xml+userdb
和application/whatever+userdb
- 可能支持许多媒体类型)。客户端和服务器都已编程为理解这种格式,但他们对彼此一无所知。正如Roy Fielding指出:
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"
}
]
}
我们可以从这个回复中说出很多。例如,我们现在知道我们可以通过POST
ing为/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的时候首先写下这个,而不是它的真实含义。我修改了答案以更好地代表真正的意义。)
老问题,新的回答方式。关于这个概念存在很多误解。我总是试着记住:
我将restful编程定义为
如果应用程序在客户端理解的媒体类型中提供资源(是数据+状态转换控件的组合),则应用程序是宁静的
要成为一个宁静的程序员,您必须尝试构建允许actor执行的应用程序。不只是暴露数据库。
仅当客户端和服务器就资源的媒体类型表示达成一致时,状态转换控制才有意义。否则,无法知道什么是控件,什么不是,以及如何执行控件。 IE浏览器如果浏览器不知道html中的<form>
标签那么你就没有什么可以在浏览器中提交过渡状态了。
我不是要自我推销,但是我在谈论http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html时将这些想法扩展到了很大的深度。
我的演讲的摘录是关于经常提到的理查森成熟度模型,我不相信等级,你要么是RESTful(3级),要么你不是,但我想说的是它是什么每个级别在你去RESTful的路上为你做的
REST定义了6个架构约束,它们构成了任何Web服务 - 一个真正的RESTful API。
REST是一种基于Web标准和HTTP协议(2000年引入)的架构风格。
在基于REST的架构中,一切都是资源(用户,订单,评论)。通过基于HTTP标准方法(GET,PUT,PATCH,DELETE等)的公共接口访问资源。
在基于REST的体系结构中,您有一个REST服务器,可以访问资源。 REST客户端可以访问和修改REST资源。
每个资源都应该支持HTTP常用操作。资源由全局ID(通常是URI)标识。
REST允许资源具有不同的表示,例如文本,XML,JSON等.REST客户端可以通过HTTP协议(内容协商)请求特定表示。
HTTP方法:
PUT,GET,POST和DELETE方法通常用于基于REST的体系结构。下表给出了这些操作的说明。
REST代表Representational状态转移。
它依赖于无状态,客户端 - 服务器,可缓存的通信协议 - 并且几乎在所有情况下都使用HTTP协议。
REST通常用于移动应用程序,社交网站,mashup工具和自动化业务流程。 REST风格强调通过使用有限数量的操作(动词)来增强客户端和服务之间的交互。通过为资源(名词)分配他们自己独特的通用资源指标(URI)来提供灵活性。
说话不仅仅是交换信息。实际上,协议的设计使得不必进行谈话。每一方都知道他们的特定工作是什么,因为它在协议中指定。协议允许纯信息交换,但代价是可能的操作有任何变化。另一方面,谈话允许一方询问可以从另一方采取进一步的行动。他们甚至可以两次提出同样的问题并得到两个不同的答案,因为另一方的国家可能在此期间发生了变化。说话是RESTful架构。菲尔丁的论文规定了如果一个人想让机器彼此交谈而不是简单地沟通就必须遵循的架构。
本身没有“RESTful编程”这样的概念。它会更好地称为RESTful范例,甚至更好的RESTful架构。它不是一种编程语言。这是一种范式。
在计算中,表示性状态转移(REST)是用于Web开发的体系结构样式。
休息点是,如果我们同意使用通用语言进行基本操作(http动词),则可以配置基础结构以理解它们并对其进行适当优化,例如,通过利用缓存标头来实现缓存水平。
通过正确实施的Restful GET操作,无论信息来自服务器的数据库,服务器的内存缓存,CDN,代理缓存,浏览器缓存还是浏览器的本地存储都无关紧要。可以使用禁食的,最容易获得的最新来源。
说Rest只是从使用带动作参数的GET请求到使用可用的http动词的语法变化,使它看起来没有任何好处,纯粹是装饰性的。关键是要使用可以被链的每个部分理解和优化的语言。如果您的GET操作具有副作用的操作,则必须跳过所有HTTP缓存,否则您将得到不一致的结果。
什么是API Testing?
API测试利用编程将调用发送到API并获得收益。它测试将被测段视为黑盒子。 API测试的目的是确认在协调到应用程序之前对其进行正确执行和错误处理。
REST API
REST:具象国家转移。
4种常用的API方法: -
手动测试API的步骤: -
要手动使用API,我们可以使用基于浏览器的REST API插件。
除了Richardson的成熟度模型是实际判断Restful是一个人的API的最佳方法之一之外,这在所有地方都很少被提及。更多关于它:
RESTful编程是关于:
Create
,Retrieve
,Update
,Delete
变成POST
,GET
,PUT
和DELETE
。但REST不仅限于HTTP,它现在只是最常用的传输方式。就REST的后果和整体有效性而言,最后一个可能是最重要的。总体而言,大多数RESTful讨论似乎都集中在HTTP及其在浏览器中的使用,而不是。我理解R.Fielding在描述导致HTTP的架构和决策时创造了这个术语。他的论文更多地是关于资源的体系结构和缓存能力,而不是HTTP。
如果您真的对RESTful架构及其工作原理感兴趣,请阅读his thesis几次并阅读整篇文章,而不仅仅是第5章!接下来看看why DNS works。了解DNS的层次结构以及推介的工作原理。然后阅读并考虑DNS缓存的工作原理。最后,阅读HTTP规范(特别是RFC2616和RFC3040)并考虑缓存的工作方式和原因。最终,它只会点击。对我来说,最后的启示是当我看到DNS和HTTP之间的相似之处时。在此之后,了解SOA和消息传递接口可扩展的原因开始单击。
我认为理解RESTful和Shared Nothing体系结构的体系结构重要性和性能影响的最重要技巧是避免陷入技术和实现细节。专注于谁拥有资源,谁负责创建/维护它们等等。然后考虑表示,协议和技术。
我会说理解REST的一个重要组成部分在于端点或映射,例如/customers/{id}/balance
。
您可以将这样的端点想象成从网站(前端)到数据库/服务器(后端)的连接管道。使用它们,前端可以执行后端操作,这些操作在应用程序中任何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>
修改记录(lname
和age
将保持不变):
PATCH /user/123
fname=Johnny
要更新记录(因此lname
和age
将为NULL):
PUT /user/123
fname=Johnny
一本关于REST的好书是REST in Practice。
必读的是Representational State Transfer (REST)和REST APIs must be hypertext-driven
有关RESTful服务的解释,请参阅Martin Fowlers的文章Richardson Maturity Model(RMM)。
要成为RESTful服务需要满足Hypermedia as the Engine of Application State. (HATEOAS),也就是说,它需要达到RMM中的3级,read the article以获取详细信息或slides from the qcon talk。
HATEOAS约束是Hypermedia作为应用程序状态引擎的首字母缩写。此原则是REST与大多数其他形式的客户端服务器系统之间的关键区别。
...
RESTful应用程序的客户端只需知道一个固定的URL即可访问它。所有未来的操作都应该可以从包含在从该URL返回的资源的表示中的超媒体链接动态发现。任何可能使用RESTful API的客户端都应该理解标准化媒体类型。 (维基百科,自由的百科全书)
REST Litmus Test for Web Frameworks是一个类似的Web框架成熟度测试。
Approaching pure REST: Learning to love HATEOAS是一个很好的链接集合。
REST versus SOAP for the Public Cloud讨论了REST使用的当前级别。
REST and versioning通过可修改性讨论了可扩展性,版本控制,可演化性等
什么是REST?
REST代表Representational State Transfer。 (它有时拼写为“ReST”。)它依赖于无状态,客户端 - 服务器,可缓存的通信协议 - 并且几乎在所有情况下都使用HTTP协议。
REST是一种用于设计网络应用程序的架构风格。我们的想法是,不是使用CORBA,RPC或SOAP等复杂机制来连接机器,而是使用简单的HTTP在机器之间进行调用。
在许多方面,基于HTTP的万维网本身可以被视为基于REST的架构。 RESTful应用程序使用HTTP请求来发布数据(创建和/或更新),读取数据(例如,进行查询)和删除数据。因此,REST对所有四个CRUD(创建/读取/更新/删除)操作使用HTTP。
REST是RPC(远程过程调用)和Web服务(SOAP,WSDL等)机制的轻量级替代方法。稍后,我们将看到REST更简单。
尽管简单,但REST功能齐全;在Web服务中基本上没有什么可以用RESTful架构完成的。 REST不是“标准”。例如,REST永远不会有W3C推荐。虽然有REST编程框架,但使用REST非常简单,您可以经常使用Perl,Java或C#等语言中的标准库功能“自己动手”。
当我试图找到休息的简单真实含义时,我发现了最好的参考之一。
REST使用各种HTTP方法(主要是GET / PUT / DELETE)来操作数据。
您可以向/user/123/delete
URL发送DELETE请求,编辑用户,检索向您发送GET请求的用户的信息,而不是使用特定的URL来删除方法(例如,/user/[id]
),/user/[id]
例如,而是一组可能看起来像以下某些内容的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
这是一个编程,你的系统架构适合由Roy Fielding在REST style布置的his thesis。由于这是描述网络的架构风格(或多或少),很多人对此感兴趣。
奖励答案:不会。除非您正在学习软件架构作为学术或设计Web服务,否则没有理由听到这个术语。
我想说RESTful编程将是关于创建遵循REST架构风格的系统(API)。
我找到了M. Elkstein博士关于REST的精彩,简短且易于理解的教程,并引用了大部分内容可以回答你的问题:
REST是一种用于设计网络应用程序的架构风格。我们的想法是,不是使用CORBA,RPC或SOAP等复杂机制来连接机器,而是使用简单的HTTP在机器之间进行调用。
- 在许多方面,基于HTTP的万维网本身可以被视为基于REST的架构。
RESTful应用程序使用HTTP请求来发布数据(创建和/或更新),读取数据(例如,进行查询)和删除数据。因此,REST对所有四个CRUD(创建/读取/更新/删除)操作使用HTTP。
我认为你不应该因为没有听到Stack Overflow之外的REST而感到愚蠢......,我会处于同样的境地!关于Why is REST getting big now的另一个问题的答案可以缓解一些感受。