RESTful编程究竟是什么？

牛青 • 2022年8月26日 pm7:43 • 问答 • 112 阅读

RESTful编程究竟是什么？

回答

REST是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 - 可能支持许多媒体类型).客户端和服务器都已编程为理解这种格式,但他们对彼此一无所知.正如Roy Fielding指出:

对基本资源的请求GET可能返回如下内容:

请求

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"
}
]
}

我们从媒体的描述中了解到,我们可以从名为"链接"的部分找到有关相关资源的信息.这称为超媒体控件.在这种情况下,我们可以从这样的部分告诉我们可以通过另外请求找到用户列表POST:

请求

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来创建一个新用户PUT:

请求

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不仅仅是另一个流行语.它是一种描述基于SOAP的数据交换的替代方法的手段.术语REST有助于构建有关如何传输和访问数据的讨论.
尽管如此,REST的核心(在实际应用中)是"不使用GET进行更改,使用POST/PUT/DELETE",这是我在SOAP出现之前就已经听过(和跟随)的建议.REST*总是在那里,它直到最近才获得超越"实现方式"的名称.
这个答案忽略了这一点.菲尔丁的论文中几乎没有提到HTTP.
不要忘记"超文本作为应用程序状态的引擎".
这个答案没有提到REST的目的,并使它看起来像是关于干净的URI.虽然这可能是人们对REST的普遍看法,但是,D.Shawley和oluies的答案更准确 - 它是关于能够利用体系结构中内置的功能,如缓存,通过使用它而不是反对它.更漂亮的URI主要是常见的副作用.
1)停止将CRUD与HTTP动词混淆.2)REST不是没有超媒体的REST(HATEOAS),它只是HTTP.3)REST不讨论URI的格式,只讨论使用这些资源的表示来操作资源.
@Rafe这不是REST的问题,这是Web浏览器的问题!我们中的一些人在没有Web浏览器的情况下使用REST 🙂
@ user35,@ TR,当然你对这一切都是正确的,我同意你的看法.但正是因为这是一个如此复杂的想法,大多数人都不会对这个概念的细节感兴趣(甚至不能够).我的解释是一个过于简化的例子,说明当一些RESTful原则应用于最常见的用例 - 基于http的Web服务时的样子.我仍然认为我的答案足够好,作为一个快速的五分钟介绍,但当然我鼓励任何人更详细地阅读它,例如本页面上的其他更好的答案.
这很复杂,而且您的描述并不准确.我之所以提出这个问题,是因为有些人误以为REST是一项没有实际好处的工作,因此严格来说是学术性的,没有意识到它的目标是非常实用的东西,比如可扩展性.我认为最重要的答案是不能被误解为支持这种误解,所以我感谢你努力解决我的投诉.
如果围绕某个主题存在广泛的误解,那么以受欢迎的名义延续这种做法违背了社区维基的目的.由于改变了原作者,我不知道不诚实的地方.相反,对他而言,这是非常诚实的,并反映了他对这一主题的改进知识.
我很惊讶HATEOAS没有早起.
@Dave Sherohman,不是REST,只是正确使用HTTP.
与REST的问题是,浏览器不支持PUT和DELETE,所以你必须使用POST包含你会喜欢使用,但不能在法假冒这些方法和隐藏的表单参数.
令人惊讶的是,一个完全误导并完全忽略这一点的答案如此受欢迎.这个答案不仅仅是不完整的,正如作者在编辑中所建议的那样.这绝对是错的.
这个新的答案完全是错误的**,用流行语来搭载,实际上并没有表明你是如何编程的.当有人问你做什么烹饪时,你不回答"热力学是物理学的基本原理!".将原始答案转换为此社区维基是一个错误.

称为REST(Representational State Transfer)的架构风格提倡Web应用程序应该像最初设想的那样使用HTTP .查找应该使用请求.,和请求应分别用于变异,创建和删除.GETPUTPOSTDELETE

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请求份额.

这取自David M. Geary 的优秀书籍Core JavaServer面子书.

这是错的.阅读本文以正确解释REST http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven或此/sf/ask/1389043631/ API-和后法/ 19844272#19844272
a)关于GET的重要一点是安全性,而不是幂等性,b)@Abhijeet:RFC 2616已于2014年废弃; 见RF 7230ff.
@kushalvm REST的学术定义在实践中没有使用.
实际上,我们可以怀疑一个概念是否可操作,因为我们不能简单地为所有人提供一个稳定且易于理解的定义
Lisiting可用的幂等操作:GET(安全),PUT和DELETE(此链接中提到了异常restapitutorial.com/lessons/idempotency.html).安全和幂等方法的附加参考w3.org/Protocols/rfc2616/rfc2616-sec9.html

RESTful编程是关于:

由持久性标识符标识的资源:URI是当今无处不在的标识符选择
资源使用一组共同的动词被操纵:HTTP方法是常见的情况-古老Create,Retrieve,Update,Delete变POST,GET,PUT,和DELETE.但REST不仅限于HTTP,它现在只是最常用的传输方式.
为资源检索的实际表示取决于请求而不是标识符:使用Accept标头来控制是否需要XML,HTTP,甚至是表示资源的Java对象
维护对象中的状态并表示表示中的状态
表示资源表示中资源之间的关系:对象之间的链接直接嵌入表示中
资源表示描述了如何使用表示以及在什么情况下应该以一致的方式丢弃/重新获取表示:HTTP Cache-Control头的使用

就REST的后果和整体有效性而言,最后一个可能是最重要的.总体而言,大多数RESTful讨论似乎都集中在HTTP及其在浏览器中的使用,而不是.我理解R.Fielding在描述导致HTTP的架构和决策时创造了这个术语.他的论文更多地是关于资源的体系结构和缓存能力,而不是HTTP.

如果您真的对RESTful架构是什么以及它的工作原理感兴趣,请阅读他的论文几次并阅读整篇文章而不仅仅是第5章!接下来看看DNS的工作原理.了解DNS的层次结构以及推介的工作原理.然后阅读并考虑DNS缓存的工作原理.最后,阅读HTTP规范(特别是RFC2616和RFC3040)并考虑缓存如何以及为什么以它的方式工作.最终,它只会点击.对我来说最后的启示是当我看到DNS和HTTP之间的相似之处时.在此之后,了解SOA和消息传递接口可扩展的原因开始单击.

我认为理解RESTful和Shared Nothing架构的架构重要性和性能影响的最重要技巧是避免陷入技术和实现细节.专注于谁拥有资源,谁负责创建/维护它们等等.然后考虑表示,协议和技术.

提供阅读清单的答案非常适合这个问题.
感谢更新.`PUT`和`POST`并没有真正地与更新和创建一对一地映射.如果客户端指示URI将是什么,则可以使用`PUT`来创建.如果服务器正在分配新URI,则`POST`会创建.
别忘了PATCH.
URN是使用`urn:`方案的URI.从概念上讲,没有区别; 但是,URN确实要求您使用单独定义的方法来"定位"URN标识(命名)的资源.必须注意确保在关联命名资源及其位置时不引入隐式耦合.
@ellisbben同意.如果我理解正确,这是引起REST的论文:http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

这可能是它的样子.

创建具有三个属性的用户:

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

在最后一个例子中,@ pbreitenbach使用`PUT fname = Jonny`.这会将`lname`和`age`设置为默认值(可能是NULL或空字符串,整数0),因为`PUT`**用来自所提供的表示的数据覆盖整个资源**.这不是"更新"所暗示的,**进行真正的更新,使用`PATCH`方法**,因为这不会改变表示中未指定的字段.
对我来说,这个答案抓住了所期望答案的本质.简单务实.当然,还有很多其他标准,但提供的示例是一个很棒的发射台.
尼古拉斯是对的.此外,创建用户的第一个POST的URI应该被称为用户,因为`/ user/1`是没有意义的,并且应该在`/ users`上有一个列表.响应应该是"201 Created",而不仅仅是OK.

一本关于REST的好书是REST in Practice.

必须读取是Representational State Transfer(REST),REST API必须是超文本驱动的

有关RESTful服务的解释,请参阅Martin Fowlers文章Richardson成熟度模型(RMM).

要成为RESTful,服务需要将超媒体作为应用程序状态的引擎来实现.(HATEOAS),也就是说,它需要在RMM中达到3级,阅读文章以获取详细信息或qcon谈话中的幻灯片.

...

RESTful应用程序的客户端只需知道一个固定的URL即可访问它.所有未来的操作都应该可以从包含在从该URL返回的资源的表示中的超媒体链接动态发现.任何可能使用RESTful API的客户端都应该理解标准化媒体类型.(维基百科,自由的百科全书)

REST Litmus Test for Web Frameworks是一个类似的Web框架成熟度测试.

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

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

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

我认为这个答案触及了理解REST的关键点:**代表**的含义是什么意思.1级 - 资源说关于*州*.2级 - HTTP动词说关于*transfer*(读*更改*).3级 - HATEOAS表示通过表示(JSON/XML/HTML返回)驱动未来转移,这意味着您已经知道如何用返回的信息说下一轮谈话.所以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#等语言中的标准库功能"自己动手".

当我试图找到休息的简单真实含义时,我发现了最好的参考之一.

http://rest.elkstein.org/

REST使用各种HTTP方法(主要是GET/PUT/DELETE)来操作数据.

/user/123/delete您可以向/user/[id]URL 发送DELETE请求,编辑用户,检索发送GET请求的用户的信息,而不是使用特定的URL来删除方法(例如)./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

这是"正确使用HTTP",这与"restful"不同(尽管它与之相关)
瓦迪姆,那简直就是RPC.使用GET修改数据也很危险,因为(除其他原因外)搜索引擎可能会抓取您的删除链接并访问它们.
@aehlke - 我认为真正的问题是"为什么匿名用户能够从系统中删除记录？"
你也可以使用/ user/del/2和/ user/remove/2或...... GET/DELETE/PUT/POST只是标准化,"正确"的方式来做这些事情(正如朱利安所说,并非全部有REST)

这是一个编程,你的系统架构符合Roy Fielding在论文中提出的REST风格.由于这是描述网络的架构风格(或多或少),很多人对此感兴趣.

奖励答案:不会.除非您正在学习软件架构作为学术或设计Web服务,否则没有理由听到这个术语.

此外,即使术语REST和RESTful现在几乎只在Web应用程序领域中使用,从技术上讲,没有什么可以将REST与HTTP联系起来.
Fielding的博客有一些很好的,更容易理解关于REST和常见误解的文章:http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
@HankGay我认为它不是更深奥的原因是大多数Web服务开发人员将REST看作是对SOAP之类的替代方案的精彩简化.他们并不一定坚持让所有REST技术都正确 - 这可能会让REST狂热分子疯狂 - 但在大多数情况下,他们可能不需要担心确保他们的结果是"超媒体启用"之类的事情.
但不是直截了当的......它使它变得更加复杂.

我想说RESTful编程将是关于创建遵循REST架构风格的系统(API).

我找到了M. Elkstein博士关于REST的精彩,简短且易于理解的教程,并引用了大部分内容可以回答你的问题:

学习REST:教程

在许多方面,基于HTTP的万维网本身可以被视为基于REST的架构.

RESTful应用程序使用HTTP请求发布数据(创建和/或更新),读取数据(例如,进行查询)和删除数据.因此,REST对所有四个CRUD(创建/读取/更新/删除)操作使用HTTP.

我认为你不应该因为没有听到Stack Overflow之外的REST而感到愚蠢......,我会处于同样的境地!关于为什么REST现在变大的另一个问题的答案可以缓解一些感受.

如果我没有直接回答这个问题,我会道歉,但通过更详细的例子更容易理解这一切.由于所有的抽象和术语,Fielding不容易理解.

这里有一个相当不错的例子:

解释REST和超文本:Spam-E垃圾邮件清理机器人

更好的是,这里有一个简单的例子清晰的解释(powerpoint更全面,但你可以在html版本中获得大部分内容):

http://www.xfront.com/REST.ppt或http://www.xfront.com/REST.html

阅读完示例后,我可以看出为什么Ken说REST是超文本驱动的.我不确定他是对的,因为/ user/123是一个指向资源的URI,而且我不清楚它是不是因为客户端"带外"知道它是不可靠的.

该xfront文档解释了REST和SOAP之间的区别,这也非常有用.当Fielding说," 那就是RPC.它会尖叫RPC. ",很明显RPC并不是RESTful,因此查看确切原因很有用.(SOAP是一种RPC.)

很酷的链接,谢谢.我厌倦了这些REST家伙,他们说一些例子不是"REST-ful",但后来拒绝说如何将这个例子改为REST-ful.

什么是REST？

REST官方话说,REST是一种基于某些原则的架构风格,使用当前的"Web"基础.Web有5个基本基础,可用于创建REST服务.

原则1:一切都是资源在REST架构风格中,数据和功能被视为资源,并使用统一资源标识符(URI)(通常是Web上的链接)进行访问.
原则2:每个资源都由唯一标识符(URI)标识
原则3:使用简单和统一的接口
原则4:通过代表进行沟通
原则5:无国籍

“通过代表进行沟通”是什么意思？

我看到一堆答案,说将用户123的所有内容放在资源"/ user/123"上是RESTful.

创造这个术语的罗伊菲尔丁说,REST API必须是超文本驱动的.特别是,"REST API不能定义固定资源名称或层次结构".

因此,如果您的"/ user/123"路径在客户端上是硬编码的,那么它并不是真正的RESTful.很好地利用HTTP,也许不是.但不是RESTful.它必须来自超文本.

好吧..你能进一步解释一下吗？什么是说"没有这些家伙是错的......我知道什么是对的"而没有说出你知道(或认为)对的是什么？
那......这个例子怎么样才能安息？你怎么改变网址让它变得安静？
我给了Fielding的描述链接.我以为我确切地说过与其他答案相关的差异:需要由超文本驱动.如果"/ user/123"来自某些带外API文档,那么它不是RESTful.如果它来自您的超文本中的资源标识符,那么它就是.
@Andy：当您将硬编码 URL 放入 **client** 时，它就不再是 RESTful。特别是，RESTful 服务可能会一时兴起决定对用户重新编号，这会破坏非 RESTful 客户端。当无法从记录的入口点发现 `/user/123/` 时，该服务将停止使用 RESTful，这确实意味着所有客户端都必须对该 URL 进行硬编码。

答案非常简单,有一篇由Roy Fielding撰写的论文.] 1在那篇论文中,他定义了REST原则.如果应用程序满足所有这些原则,那么这就是REST应用程序.

创建RESTful一词是因为ppl通过将非REST应用程序称为REST来耗尽REST这个词.之后,RESTful这个词也用尽了.现在我们讨论的是Web API和超媒体API,因为大多数所谓的REST应用程序都没有满足统一接口约束的HATEOAS部分.

REST约束如下:

因此它不适用于例如PUB/SUB套接字,它基于REQ/REP.
因此服务器不维护客户端的状态.这意味着您无法使用服务器端会话存储,您必须验证每个请求.您的客户端可能通过加密连接发送基本身份验证标头.(通过大型应用程序,很难维持很多会话.)
因此,您不必一次又一次地提供相同的请求.
服务器不维护客户端和服务器之间的合同.换句话说,客户端必须与服务的实现分离.您可以通过使用标准解决方案来达到此状态,例如用于标识资源的IRI(URI)标准,用于交换消息的HTTP标准,用于描述正文序列化格式的标准MIME类型,元数据(可能是RDF词汇,微格式等)到描述消息体不同部分的语义.要将IRI结构与客户端分离,您必须以超媒体格式(如HTML,JSON-LD,HAL等)向客户端发送超链接.因此,客户端可以使用分配给超链接的元数据(可能是链接关系,RDF词汇)来通过适当的状态转换来导航应用程序的状态机,以便实现其当前目标.

例如,当客户想要向网上商店发送订单时,它必须检查网上商店发送的响应中的超链接.通过检查链接,它找到了一个用http://schema.org/OrderAction描述的链接.客户端知道schema.org词汇,因此它了解通过激活此超链接,它将发送订单.因此它激活超链接并发送POST https://example.com/api/v1/order带有正确正文的消息.之后,服务处理消息并以具有正确HTTP状态标头的结果作出响应,例如201 - created通过成功.要使用详细元数据注释消息,使用RDF格式的标准解决方案,例如带有REST词汇的JSON-LD,例如Hydra和域名特定词汇,如schema.org或任何其他链接数据词汇,也可能是自定义应用程序特定词汇需要.现在这并不容易,这就是为什么大多数人使用HAL和其他简单格式的原因,这些格式通常只提供REST词汇,但没有链接数据支持.
REST系统由分层结构组成.每个层都包含使用下一层中组件服务的组件.因此,您可以毫不费力地添加新的图层和组件.

例如,有一个包含客户端的客户端层,下面是一个包含单个服务的服务层.现在,您可以在它们之间添加客户端缓存.之后,您可以添加另一个服务实例和负载均衡器,等等......客户端代码和服务代码不会更改.
此约束是可选的.例如,您可以将特定媒体类型的解析器发送到客户端,依此类推......为了做到这一点,您可能需要在客户端中使用标准插件加载器系统,或者您的客户端将耦合到插件加载器解决方案.

REST约束导致高度可扩展的系统,其中客户端与服务的实现分离.因此,客户端可以重复使用,就像网络上的浏览器一样.客户端和服务共享相同的标准和词汇,因此尽管客户端不知道服务的实现细节,但他们可以相互理解.这使得创建自动化客户端成为可能,这些客户端可以找到并利用REST服务来实现其目标.从长远来看,这些客户可以相互沟通,相互信任,就像人类一样.如果我们向这样的客户端添加学习模式,那么结果将是使用机器网而不是单个服务器园的一个或多个AI.所以最后伯纳斯李的梦想:语义网和人工智能将成为现实.所以在2030年我们终于被天网终止了.直到那时 ... 😉

RESTful(Representational state transfer)API编程通过遵循5种基本软件架构风格原则,以任何编程语言编写Web应用程序:

资源(数据,信息).
唯一的全局标识符(所有资源都是由URI标识的唯一标识).
统一接口 - 使用简单和标准接口(HTTP).
表示 - 所有通信都通过表示(例如XML/JSON)完成
无状态(每个请求都完全隔离,缓存和负载平衡更容易),

换句话说,您正在通过HTTP编写简单的点对点网络应用程序,它通过实现RESTful架构来使用诸如GET,POST,PUT或DELETE之类的动词,该架构提出了每个"资源"公开的接口的标准化.以简单有效的方式使用Web的当前功能(非常成功,经过验证和分布式架构)并不是什么.它是SOAP,CORBA和RPC等更复杂机制的替代方案.

RESTful编程符合Web架构设计,如果实施得当,它可以让您充分利用可扩展的Web基础架构.

如果我不得不将关于REST的原始论文减少到只有3个短句,我认为以下内容抓住了它的本质:

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

在那之后,很容易陷入有关改编,编码惯例和最佳实践的争论中.

有趣的是,论文中没有提到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.

编辑:两个更重要的方面:

- REST,对资源表示进行操作,每个表示由URL标识.这些通常不是数据对象,而是复杂的对象抽象.
- REST代表"代表性状态转移",这意味着它是关于在系统中传递和修改某些资源的状态.

老问题,新的回答方式.关于这个概念存在很多误解.我总是试着记住:

结构化URL和Http方法/动词不是restful编程的定义.
JSON不是宁静的编程
RESTful编程不适用于API

我将restful编程定义为

要成为一个宁静的程序员,您必须尝试构建允许actor执行的应用程序.不只是暴露数据库.

仅当客户端和服务器就资源的媒体类型表示达成一致时,状态转换控制才有意义.否则,无法知道什么是控件,什么不是,以及如何执行控件.IE浏览器如果浏览器不知道<form>html中的标签,那么您无需在浏览器中提交过渡状态.

我不是在寻求自我推销,但我在演讲中深入探讨了这些想法http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html.

我的演讲的摘录是关于经常提到的理查森成熟度模型,我不相信等级,你要么是RESTful(3级),要么你不是,但我喜欢称之为它是什么每个级别在你去RESTful的路上为你做的

这是非常长的"讨论",但至少可以说是相当混乱.

IMO:

1)没有宁静的编程,没有大关节和大量的啤酒:)

2)具象国家转移(REST)是罗伊菲尔丁论文中规定的建筑风格.它有许多限制.如果您的服务/客户尊重这些,那么它就是RESTful.就是这个.

您可以(显着地)将约束汇总到:

无国籍的沟通
尊重HTTP规范(如果使用HTTP)
清楚地传达传输的内容格式
使用超媒体作为应用程序状态的引擎

还有一个非常好的帖子可以很好地解释事情.

许多答案复制/粘贴有效信息混合它并添加一些混淆.人们在这里谈论层次,关于RESTFul URI(没有这样的东西!),应用HTTP方法GET,POST,PUT ...... REST不仅仅是关于那个问题.

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

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

REST定义了6个架构约束,它们构成了任何Web服务 - 一个真正的RESTful API.

统一界面
客户端服务器
无状态
可缓存
分层系统
按需代码(可选)

https://restfulapi.net/rest-architectural-constraints/

REST === HTTP类比是不正确的,直到你不强调它"必须"被HATEOAS驱动的事实.

罗伊自己在这里清除了它.

应输入REST API,除了初始URI(书签)和适用于目标受众的标准化媒体类型集之外没有任何先验知识(即,任何可能使用API的客户都应该理解).从那时起,所有应用程序状态转换必须由客户端选择服务器提供的选择来驱动,这些选择存在于接收的表示中或者由用户对这些表示的操纵所暗示.转换可以由客户端对媒体类型和资源通信机制的知识来确定(或限制),这两者都可以在运行中(例如,按需代码)进行改进.

[失败在这里意味着带外信息驱动交互而不是超文本.]

在基于REST的架构中,一切都是资源(用户,订单,评论).通过基于HTTP标准方法(GET,PUT,PATCH,DELETE等)的公共接口访问资源.

每个资源都应该支持HTTP常用操作.资源由全局ID(通常是URI)标识.

REST允许资源具有不同的表示,例如文本,XML,JSON等.REST客户端可以通过HTTP协议(内容协商)请求特定表示.

HTTP方法:

PUT,GET,POST和DELETE方法通常用于基于REST的体系结构.下表给出了这些操作的说明.

GET定义了资源的读取访问权限,没有副作用.资源永远不会通过GET请求更改,例如,请求没有副作用(幂等).
PUT创建一个新资源.它也必须是幂等的.
DELETE删除资源.这些操作是幂等的.它们可以重复而不会导致不同的结果.
POST更新现有资源或创建新资源.

REST代表Representational状态转移.

它依赖于无状态,客户端 - 服务器,可缓存的通信协议 - 并且几乎在所有情况下都使用HTTP协议.

REST通常用于移动应用程序,社交网站,mashup工具和自动化业务流程.REST风格强调通过使用有限数量的操作(动词)来增强客户端和服务之间的交互.通过为资源(名词)分配他们自己独特的通用资源指标(URI)来提供灵活性.

关于休息的介绍

说话不仅仅是交换信息.实际上,协议的设计使得不必进行谈话.每一方都知道他们的特定工作是什么,因为它在协议中指定.协议允许纯信息交换,但代价是可能的操作有任何变化.另一方面,谈话允许一方询问可以从另一方采取进一步的行动.他们甚至可以两次提出同样的问题并得到两个不同的答案,因为另一方的国家可能在此期间发生了变化.说话是RESTful架构.菲尔丁的论文规定了如果一个人想让机器彼此交谈而不是简单地沟通就必须遵循的架构.

本身没有"RESTful编程"这样的概念.它会更好地称为RESTful范例,甚至更好的RESTful架构.它不是一种编程语言.这是一种范式.

来自维基百科:

休息点是,如果我们同意使用通用语言进行基本操作(http动词),则可以配置基础结构以理解它们并对其进行适当优化,例如,通过利用缓存标头来实现缓存水平.

通过正确实施的Restful GET操作,无论信息来自服务器的数据库,服务器的内存缓存,CDN,代理缓存,浏览器缓存还是浏览器的本地存储都无关紧要.可以使用禁食的,最容易获得的最新来源.

说Rest只是从使用带动作参数的GET请求到使用可用的http动词的语法变化,使它看起来没有任何好处,纯粹是装饰性的.关键是要使用可以被链的每个部分理解和优化的语言.如果您的GET操作具有副作用的操作,则必须跳过所有HTTP缓存,否则您将得到不一致的结果.

"说休息只是一种语法上的改变......让它看起来没有任何好处,而且纯粹是装饰性的" - 这正是我在这里阅读答案的原因.请注意,您没有解释,为什么REST不是纯粹的装饰.

这个答案是针对绝对初学者的，让我们了解当今最常用的 API 架构。

了解 Restful 编程或 Restful API。首先，您必须了解 API 是什么，在非常高级的 API 代表应用程序编程接口，它基本上是一个软件，可以由另一个软件使用，以便允许应用程序相互通信。

全球使用最广泛的 API 类型是 Web API，而应用程序会在请求到来时向客户端发送数据。

事实上，API 不仅用于发送数据，而且并不总是与 Web 开发或 javascript 或 python 或任何编程语言或框架相关。

API 中的应用程序实际上可以意味着很多不同的东西，只要软件是相对独立的。以文件系统或 HTTP 模块为例，我们可以说它们是小软件，我们可以使用它们，我们可以通过它们的 API 与它们交互。例如，当我们对任何编程语言的文件系统模块使用读取文件功能时，我们实际上是在使用 file_system_reading API。或者当我们在浏览器中进行 DOM 操作时，我们并没有真正使用 JavaScript 语言本身，而是使用浏览器向我们公开的 DOM API，因此它让我们可以访问它。或者再举一个例子，假设我们用任何编程语言（如 Java）创建一个类，然后向其中添加一些公共方法或属性，这些方法将成为从该类创建的每个对象的 API，因为我们为其他软件提供了与我们的初始软件（在本例中为对象）交互的可能性。S0，API 实际上比仅仅构建 Web API 具有更广泛的含义。

现在让我们看一下构建 API 的 REST 架构。

代表 Representational State Transfer 的REST基本上是一种以逻辑方式构建 Web API 的方式，使它们易于为我们自己或他人使用。

要按照 REST 架构构建 Restful API，我们只需要遵循几个原则。1. 我们需要将我们的 API 分离成逻辑资源。2. 然后应使用基于资源的 URL 公开这些资源。3. 要对数据执行不同的操作，例如读取、创建或删除数据，API 应使用正确的 HTTP 方法而不是 URL。4. 现在我们实际发送回客户端或从客户端接收到的数据通常应该使用 JSON 数据格式，是对其应用了一些格式标准。5. 最后，EST API 的另一个重要原则是它们必须是无状态的。

将 API 划分为逻辑资源： REST 中信息的关键抽象是资源，因此我们要在 API 中共享的所有数据都应该划分为逻辑资源。资源究竟是什么？好吧，在 REST 的上下文中，它是一个对象或某种事物的表示，它具有与之关联的一些数据。例如，诸如导游、用户、地点或评论之类的应用程序是逻辑资源的示例。所以基本上任何可以命名的信息都可以成为资源。不过，只需要命名，而不是动词。

公开结构：现在我们需要公开，这意味着使用一些结构化的 URL 使数据可用，客户端可以向其发送请求。例如，像整个地址这样的东西称为 URL。这个 /addNewTour 被调用和 API 端点。

我们的 API 将有许多不同的端点，如下所示

https://www.tourguide.com/addNewTour
https://www.tourguide.com/getTour
https://www.tourguide.com/updateTour
https://www.tourguide.com/deleteTour
https://www.tourguide.com/getRoursByUser
https://www.tourguide.com/deleteToursByUser

这些 API 中的每一个都会将不同的数据发送回客户端，并执行不同的操作。现在这些端点有一些非常错误的地方，因为它们确实不遵循第三条规则，即我们应该只使用 HTTP 方法来对数据执行操作。所以端点应该只包含我们的资源，而不是我们对它们执行的操作，因为它们很快就会成为维护的噩梦。

在实践中我们应该如何使用这些 HTTP 方法？好吧，让我们看看这些端点实际上应该如何以 /getTour 开头。所以这个 getTour 端点是为了获取关于旅游的数据，所以我们应该简单地命名端点 /tours 并在向这个端点发出获取请求时发送数据。所以换句话说，当客户端使用 GET HTTP 方法访问端点时，

（我们只有在端点或 URL 中有资源，没有动词，因为动词现在在 HTTP 方法中，对吗？通常的做法是始终使用复数形式的资源名称，这就是我写 /tours 或 /tour 的原因。 ) 约定是，当调用端点 /tours 时将返回数据库中的所有游览，但如果我们只想要一个 ID 的游览，假设为 7，则我们在另一个斜杠之后添加该 7(/tours/7)或在搜索查询 (/tours?id=7) 中，当然，它也可以是旅游的名称而不是 ID。

HTTP 方法：这里真正重要的是端点名称如何与所有名称完全相同。

GET: (for requesting data from the server.)
https://www.tourguide.com/tours/7
POST: (for sending data to the server.)
https://www.tourguide.com/tours
PUT/PATCH: (for updating requests for data to the server.) https://www.tourguide.com/tours/7
DELETE: (for deleting request for data to the server.)
https://www.tourguide.com/tours/7

PUT 和 PATCH 的区别-> 使用 PUT 时，客户端应该发送整个更新的对象，而使用 PATCH 时，它应该只发送对象中已更改的部分。

通过使用 HTTP 方法，用户可以执行基本的四种 CRUD 操作，CRUD 代表创建、读取、更新和删除。

现在可能会出现如下情况：

因此，/getToursByUser 可以简单地转换为 /users/tours，因为用户编号 3 的端点将类似于 /users/3/tours。

如果我们想删除特定用户的特定游览，那么 URL 应该类似于 /users/3/tours/7，这里是 user id:3 和 tour id: 7。

所以真的有很多像这样组合资源的可能性。

以 JSON 格式发送数据：现在关于客户端实际接收的数据，或者服务器从客户端接收的数据，通常我们使用 JSON 数据格式。典型的 JSON 可能如下所示：

在发送 JSON 数据之前，我们通常会做一些简单的响应格式化，对此有几个标准，但其中一个非常简单，称为 Jsend。我们只需创建一个新对象，然后向其添加状态消息，以通知客户端请求是成功、失败还是错误。然后我们将原始数据放入一个名为 Data 的新对象中。

像我们在这里所做的那样将数据包装到一个额外的对象中称为 Enveloping，这是缓解一些安全问题和其他问题的常见做法。

Restful API 应该始终是无状态的：最后，RESTful API 应该始终是无状态的，这意味着在无状态 RESTful API 中，所有状态都在客户端处理，而不是在服务器上。状态只是指应用程序中可能随时间变化的一段数据。例如，某个用户是否已登录或在一个包含多个页面的列表的页面上，当前页面是什么？现在应该在客户端处理状态这一事实意味着每个请求必须包含在服务器上处理某个请求所需的所有信息。因此，服务器永远不必为了处理当前请求而记住前一个请求。

假设目前我们在第五页，我们想前进到第六页。所以我们可以有一个名为 /tours/nextPage 的简单端点并向服务器提交请求，但服务器必须确定当前页面是什么，并基于该服务器将下一页发送到客户端。换句话说，服务器必须记住之前的请求。这正是我们想要在 RESTful API 中避免的。

而不是这种情况，我们应该创建一个 /tours/page 端点并将数字 6 粘贴到它以请求第 6 页 /tours/page/6 。所以服务器不需要记住任何东西，它所要做的就是按照我们的要求发回第六页的数据。

无状态和相反的状态是计算机科学和一般应用中非常重要的概念

什么是API测试？

API测试利用编程将调用发送到API并获得收益.它测试将被测段视为黑盒子.API测试的目的是确认在协调到应用程序之前对其进行正确执行和错误处理.

REST API

REST:具象国家转移.

它是测试人员执行请求和接收响应的功能安排.在REST API中,交互是通过HTTP协议进行的.
REST还允许计算机之间通过网络进行通信.
对于发送和接收消息,它涉及使用HTTP方法,与Web服务不同,它不需要严格的消息定义.
REST消息通常以XML或JavaScript Object Notation(JSON)的形式接受表单.

4种常用的API方法: -

GET: - 它提供对资源的只读访问权限.
POST: - 用于创建或更新新资源.
PUT: - 用于更新或替换现有资源或创建新资源.
删除: - 用于删除资源.

手动测试API的步骤: -

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

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

自动化REST API的步骤

这甚至都不是一个正确的答案

除了Richardson的成熟度模型是实际判断Restful是一个人的API的最佳方法之一之外,这在所有地方都很少被提及.更多关于它:

理查森的成熟度模型

以上是RESTful编程究竟是什么？的全部内容。

THE END

definition http rest

二维码

如何确定最初克隆本地Git存储库的URL？

< <上一篇

我应该将哪个”href”值用于JavaScript链接,”#”或”javascript:void(0)”？

下一篇>>

搜索内容

RESTful编程究竟是什么？

回答

推荐文章

最新文章

推荐阅读