当前位置:  开发笔记 > 编程语言 > 正文

我对REST的理解是什么?

如何解决《我对REST的理解是什么?》经验,为你挑选了2个好方法。

我正在构建一个框架,并希望使用它构建的开发人员能够允许其中的一部分与其他站点共享数据并允许其他站点添加/编辑/删除数据.

例如,如果有人创建了一个包含书评,作者,引用,代码示例,评论等的网站,那么开发人员可以对其他网站进行例如"书评"以及其他网站可读的"评论",并且可以通过某些网站/用户.我们的想法是使用该框架来构建可以轻松与其他应用程序互连的应用程序.

我设想通过POST和GET实现与网站的所有交互,这看起来像这样:

/books.php?category=ruby(返回关于ruby的XML集合)

/books.php?id=23(返回特定书籍的XML)

/books.php?action=add&title=AdvancedRuby&description=....&securityId=923847203487

/books.php?action=delete&id=342&securityId=923847203487

其他应用程序也可以通过这样做"发现并消费"某个站点提供的内容:

/discover.php(返回所有公共类的XML和可用的操作)

实际上,这就是我需要使框架成为开发人员快速创建松散连接站点的一种方式.

我想知道的是,在我开始实现之前,我还不了解REST的重要/有趣的部分我应该构建到框架中,例如:

REST需要GET,POST,PUT和DELETE.为什么我需要"PUT"和"DELETE"?如果我不使用这些标准,我会不会利用某些标准吗?

我的"discover.php"文件的功能类似于Web服务中的WSDL文件.我对REST的描述感到惊讶,似乎没有标准的方法来发现RESTful服务提供的服务,或者存在?

如果客户端网站试图例如将一本书添加到服务器网站并且没有得到任何"成功"响应,则它将再次尝试直到它得到响应.服务器网站根本不会两次添加同一本书.这是我对REST中数据完整性的理解,还有更多内容吗?

最终我希望有多个具有相同丰富类的站点,例如"BookReview",以便客户端站点能够执行如下代码:

$ bookReview = new BookReview(" http://www.example.com/books.php?id=23 "); $ book-> informAuthor("关于您的书评的评论已发布在我们的网站上......");

并且服务器站点将向该评论的作者发送电子邮件.这种类型的交互是RESTful哲学的一个组成部分,还是REST只是通过XML,JSON交换数据?



1> BlaM..:

如果我不使用这些标准,我会不会利用某些标准吗?

你自己从HTTP标准中锁定了.当然,你可以使用GET参数来做同样的事情.那不是REST,而是RPC-Like.

我可以推荐Leonard Richardson和Sam Ruby 撰写的RESTful Web Services一书吗?阅读并展示不同方法之间的差异非常有趣.

更详细地回答您的问题:由您决定走哪条路.理论上,您可以使用RESTful和类似RPC的方法完成所有相同的操作.REST风格的使用衬垫HTTP协议是协议.使用RPC,您只需将HTTP用作传输工具,并在传输的数据中隐藏工作订单.这导致(不必要的)开销.

看看你的两个例子:

/books.php?action=add&title=AdvancedRuby&description=....&securityId=923847203487

/books.php?action=delete&id=342&securityId=923847203487

有POST和PUT或DELETE,为什么有action = add和action = delete?

有HTTP身份验证.为什么要发明一个 - 可能不那么安全 - securityId?

顺便说一句:你不应该允许通过GET更改数据.这只是不应该做的事情(不过另一个话题;))



2> Vinko Vrsalo..:

我建议你阅读Roy Fielding的这篇文章.

一个亮点:

REST API应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型,或者为现有标准媒体类型定义扩展关系名称和/或启用超文本的标记.在媒体类型的处理规则的范围内(并且在大多数情况下,已经由现有媒体类型定义)应该完全定义用于描述在感兴趣的URI上使用什么方法的任何努力.[失败在这里意味着带外信息驱动交互而不是超文本.]

REST API不能定义固定资源名称或层次结构(客户端和服务器的明显耦合).服务器必须能够自由控制自己的命名空间.相反,允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构造适当的URI,例如在HTML表单和URI模板中完成的.[这里的失败意味着客户端由于带外信息而假设资源结构,例如特定于域的标准,这是面向数据的,与RPC的功能耦合相当].

您当然可以使用类似RPC的方法成功,并且比"适当的REST API"更容易掌握.REST中最容易被误解的方面是,一旦定义,它应该自动工作,你不应该使用这种方法来定义转到这个URI来获得答案,这应该是你提供的媒体类型所暗示的,还有一种方法可以让客户知道在哪里可以找到相关资源.


+1很棒的答案.但对我而言,Roy的帖子总是过于抽象和学术化,难以掌握并用于向人们解释如何实现REST API.我发现使用"超媒体作为应用程序状态引擎"的最佳解释是http://www.infoq.com/articles/subbu-allamaraju-rest.Subbu提供了一个具体的例子,可以将RPC样式接口(就像OP提出的那样)转换为合适的REST API,最后帮助我理解差异
推荐阅读
无名有名我无名_593
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有