实现REST

Question

实现REST

我浏览一个简单的,完全REST API的好例子,但无济于事.检查stackoverflow也是如此.我见过的最好的就是这篇文章.尽管如此,我仍然没有明白这一点.让我们举一个我们都知道的应用程序的例子:维基百科.

假设我们要为维基百科创建REST API.我们期待以下动词:

GET /wiki/Article_name: obtains a specified page
DELETE /wiki/Article_name: deletes the page
POST /wiki/Article_name: creates a new page
PUT /wiki/Article_name: updates a page.

Run Code Online (Sandbox Code Playgroud)

事实是:当您在浏览器中使用维基百科时,您不使用REST界面进行导航.我很确定当你更新页面时,你永远不会使用PUT(虽然你在技术上创建了一个新版本的页面,所以POST很有意义).同样,当您删除页面时,浏览器不会发送DELETE.

我的问题是:

REST是一个"用于浏览器"的界面还是仅用于脚本？
我们应该通过REST表示的眼睛专门看到HTTP世界吗？像GET/foo /？page = bar&action = delete这样的东西仍然是一个有效的观点,或者过去的可怕错误永远不会再次被完成？
Web访问和REST接口应该混合还是分开？例如,假设您有一个AddressBook应用程序.您可以使用GET/people /浏览地址簿,使用GET/people/1523可以在浏览器上获取该单个人信息,也可以使用漂亮的可打印HTML.如果你想修改他的卡,你会(RESTfully)PUT/people/1523,或者更喜欢PUT /api/v1.0/people/1523？
任何人都可以说服Roy Fielding获得人类,并为一个体面的(在他看来)REST API提供一个"5岁孩子"的例子,而不是抱怨什么不是RESTful(在他看来),以便全世界都可以跟进？

Answer 1

Dar*_*ler 6

REST也是"用于浏览器"的界面或仅用于脚本

都.事实上,浏览器实际上是REST客户端的一个很好的例子.它仅使用HTTP接口的子集这一事实不会违反统一接口约束.POST无论如何都是一个通配符动词.脚本在REST的描述中定义为"代码下载",并且是REST接口的组成部分.

更新: REST的统一接口约束并未说"必须使用所有可用动词"才能成为RESTful.它表示如果使用动词,则使用它来执行与预期行为一致的动作.

我们应该通过REST表示的眼睛专门看到HTTP世界吗？

否.REST通常通过HTTP完成,但HTTP不依赖于REST.但是,如果要构建Web应用程序,则应认真考虑为解决方案选择REST架构样式.它可能不是正确的选择,但它可能会是.

该请求GET /foo/?page=bar&action=delete违反了HTTP规则,因此破坏了统一接口的REST约束.但它首先打破了HTTP!

更新: 在HTTP规范RFC 2616第9.1.1节中,它声明:"特别是,已经建立了一种惯例,即GET和HEAD方法不应具有采取除检索之外的操作的重要性." 使用GET执行删除操作肯定会违反HTTP规则.

Web访问和REST接口应该混合还是分开？

在我看来,它们应该是一样的.实际上,XHTML实际上是用于提供UI和API结果的优秀格式.它是标准化的,易于解析,可在浏览器中查看以进行调试,它可以支持超媒体,微格式可用于进行语义标记,类属性可用于定义微格式无法覆盖的内容.你还能想要什么？

如果您打算使用HTML UI,为什么同样的工作需要两次？

罗伊能给我们一个简单的样品吗？

阅读如何获取一杯咖啡文章,以便了解REST API应如何工作.

在阅读文章时,请记住每个人似乎忘记的重要事实:

REST接口应该易于使用,它们不易设计.

Answer 2

Jes*_*r M 6

编辑1:正如我所看到的那样,对于大多数程序员而言,REST作为一个概念在创建API时将成为一个考虑因素.因此,当您创建供机器使用的API时,REST就会出现在您的待办事项列表中; 当你谈论人类将通过浏览器与之交互的网页时,不是这样.EDIT2:这并不意味着浏览器不是RESTful(它是).我只是说当前的行动在哪里,大多数世界程序员(那些不为浏览器制造商工作的人)可以从REST中受益的主要是在Web服务中.

让我们举一个我们都知道的应用程序的例子:维基百科.

好吧,但这不是最好的例子 - 维基百科是一个丰富的网站,即它拥有丰富的内容,而不是计算机.

GET/wiki/Article_name:获取指定的页面

DELETE/wiki/Article_name:删除页面

POST/wiki/Article_name:创建一个新页面

PUT/wiki/Article_name:更新页面.

您的数据结构基于维基百科的人类使用模型,因此存在混淆.

我正在为下面的维基百科提供一个API的快速示例,希望它有助于说明我的观点.它很快就完成了; 我并不认为它是一个很好的API设计.:-)

注1:在下面的API示例中,我使用的是JSON.就"RESTfulness"而言,它不一定是JSON,任何可以通过HTTP进行有意义交换的数据格式都可以.所以其他例子可能是XML,TXT,JPEG,AVI.从广义上讲,"RESTfulness"适用于URL和HTTP头,而不适用于页面主体 - 主体可以自由地满足特定的实现需求.

注2:我假装维基百科有一个内部的,结构化的数据格式转换为HTML页面 - 只是为了说明我的观点,因为维基百科并不是真正最好的例子......

维基百科的RESTful API的第一个镜头可能是这样的:

api.wikipedia.com/search/keywords

使用URL中的搜索词进行GET,返回页面ID,页面标题,URL和相关性分数的JSON数据集.

api.wikipedia.com/article/id/

进行GET,DELETE,POST,PUT,并对URL中内部ID等于"id"的文章进行操作.根据请求的HTTP方法,它将:

得到; 返回文章(维基百科的预定义,基于JSON的数据格式.)
删除; 删除文章
POST; 创建新文章(文章必须在请求正文中,以预定义的JSON格式)
放; 更新文章(整个页面必须在正文中重新发送)

api.wikipedia.com/media/id/

作为上面的"文章"端点,但对于图像等媒体的CRUD. ..等等,直到满足这个想象中的维基百科API的所有需求.

快速浏览上面的虚构API可以发现许多问题......这就是REST的美妙之处; 它很简单,不会妨碍数据的可视化.

REST是一个"用于浏览器"的界面还是仅用于脚本？

EDIT3原始文本是: 它不适用于浏览器,它仅适用于供其他客户端使用的API或"机器"服务.

我想将其更改为: 浏览器是RESTful.它也是一个给定的,即安装基础,以及更换IE6所需的极大时间,显然我们今天拥有的浏览器将与我们在一起很长一段时间.当前的浏览器不会对微格式或使用XHTML进行页面再现和使用XHTML进行数据传输的网站做任何特殊处理,他们会通过Javascript自行完成所有这些操作.

因此,使用当前的技术,应用REST的大多数新开发都是构建更好的Web服务API.实际考虑因素将使人们选择将其Web服务API放在与其主网站不同的URL上.

相对于其他Web服务技术,REST在易于调试方面具有显着优势.您可以在PC上启动客户端,发送URL并立即查看响应.(好吧,这在某种程度上同样适用于许多基于XML的Web服务;但是机器生成的XML对我来说是"不可读的".)

我们应该通过REST表示的眼睛专门看到HTTP世界吗？

呃,不.浏览器平均处理当今网站流量的97%？

Web访问和REST接口应该混合还是分开？

另外,在上面的示例中,我使用api.wikipedia.com来说明它与常规维基百科网站完全分开.出于实际考虑,例如负载平衡,不同的发布计划,不同的业务需求.

Web浏览器已经是RESTful客户端,无需更改即可支持REST接口.我个人觉得这很冒犯,你觉得有理由高举REST术语并应用你自己的定义与原作者不一致. (3认同)

归档时间：	16 年，2 月前
查看次数：	1546 次
最近记录：	11 年，11 月前