我正在构建一个框架，并希望使用它构建的开发人员能够允许其中的一部分与其他站点共享数据，并允许其他站点添加/编辑/删除数据。
例如，如果有人制作了一个包含书评，作者，引用，代码示例，评论等的网站，那么开发人员可以“书评”对其他网站的只读和其他网站可读并且某些网站/用户可写的“评论”。我们的想法是使用该框架来构建可以轻松与其他应用程序互连的应用程序。
我设想通过POST和GET实现与网站的所有互动，如下所示：
其他应用程序也可以“发现并消费”某个网站提供的内容：
实际上，我只需要让框架成为开发人员快速创建松散连接站点的一种方式。
我想知道的是，在我开始实现之前，我还不了解REST的重要/有趣部分我应该构建到框架中，例如：
最终我希望拥有多个具有相同富类的网站，例如“BookReview”，以便客户端站点能够执行如下代码：
$ bookReview = new BookReview（“http://www.example.com/books.php?id=23”）; $ book-＆gt; informAuthor（“有关您的图书评论的评论已发布在我们的网站上......”）;
并且服务器站点将向该评论的作者发送电子邮件。 这种类型的交互是RESTful哲学的一个组成部分，还是REST只是通过XML，JSON交换数据？
答案 0 :(得分：23)
如果我不使用这些标准，我会不会利用某些标准？
你自己已经从HTTP标准中锁定了。当然，你可以使用GET参数来做同样的事情。那不是REST，而是RPC-Like。
我可以推荐Leonard Richardson和Sam Ruby的书RESTful Web Services吗？阅读并展示不同方法之间的差异非常有趣。
更详细地回答您的问题：由您决定走哪条路。理论上，您可以使用RESTful和类似RPC的方法完成所有相同的操作。使用RESTful，您可以使用底层HTTP协议 协议。使用RPC，您只需将HTTP用作传输工具，并在传输的数据中隐藏工作订单。这导致（不必要的）开销。
看看你的两个例子：
答案 1 :(得分：8)
我建议你阅读Roy Fielding的post。
一个亮点：
REST API应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或者定义扩展的关系名称和/或支持超文本的标记。现有标准媒体类型。在媒体类型的处理规则的范围内（并且在大多数情况下，已经由现有媒体类型定义）应该完全定义用于描述在感兴趣的URI上使用什么方法的任何努力。 [失败在这里意味着带外信息驱动交互而不是超文本。]
REST API不能定义固定资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须能够自由控制自己的命名空间。相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构造适当的URI，例如在HTML表单和URI模板中完成的。 [这里的失败意味着客户端由于带外信息而假定资源结构，例如特定于域的标准，这是面向数据的，与RPC的功能耦合等效。]
您可以成功地使用类似RPC的方法，并且比“适当的REST API”更容易掌握。 REST中最容易被误解的方面是，一旦定义，它应该自动工作，你不应该使用这种方法定义转到这个URI来获得答案，这应该是媒体类型所暗示的正在提供一种方法，让客户知道在哪里可以找到相关资源。
答案 2 :(得分：4)
来自RestWiki：
考虑到这一点，将它应用到您的应用程序应该非常简单。
答案 3 :(得分：3)
使用Restlet框架，我们确实尝试在HTTP细节之上提供这种抽象级别，并使REST概念更具体（许多具有匹配的类，如Component，Connector和Representation）： http://www.restlet.org/
我们是务实的编码人员，我们的用户使用我们的RESTful框架（用于Java和GWT）开发真实应用程序。 REST支持者并非都是迂腐，但是每种主要技术都存在学习曲线。
答案 4 :(得分：2)
我会试着看看它是什么样的RESTful。
/books.php?category=ruby
GET /search?type=books&category=ruby
/books.php?id=23
GET /books/23 (or /books/23.xml)
/books.php?action=add&title=AdvancedRuby&description = ....＆安培; securityId = 923847203487
POST /books
title=AdvancedRuby&description=A+great+book...
/books.php?action=delete&id=342&securityId=923847203487
DELETE /books/342
许多开发人员坚持使用GET和POST，在这种情况下最后一个可能是：
POST /books/342
status=Deleted
答案 5 :(得分：1)
REST是一种有趣且可能有用的技术，但遗憾的是它似乎吸引了最迂腐的开发人员。
看起来他们宁愿按照REST教条来执行这个实现，尽管这意味着完全失去了功能。任何与纯REST的偏差都将被视为异端。
答案 6 :(得分：-4)
我发现没有什么可以休息的REST。对我来说，从抽象的角度来看，它是一个伟大的概念，对于那些不必处理复杂HTTP通信中涉及的更加粗糙的编码问题的网络极客来说。
如果有一个可以从所有HTTP中抽象出来的REST API，那会不会很好。但事实并非如此。相反，REST辅助者必须做一个销售工作，你可以编写这样一个API，其中包含所有伴随的调试和测试问题。
当我看到REST 1.0标题的那一天，我将再次寻找一个值得付出努力的优势。