我不了解REST？

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

例如，如果某人制作的网站包含书评，作者，引用，代码示例，评论等，则开发人员可以对其他网站进行“书评”阅读，对其他网站可阅读的“评论”某些网站/用户。这个想法是使用框架来构build可以轻松地与其他应用程序互连的应用程序。

我想通过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

其他应用程序也可以“发现并消费”某个网站必须提供的function：

真的，这是我需要使框架成为开发人员快速创build松散连接网站的一种方式。

我想知道的是，在我开始实施这个之前，REST的重要/有趣的部分，我还不知道我应该build立到框架中 ，例如：

REST需要GET，POST，PUT和DELETE。为什么我需要“PUT”和“DELETE”？如果我不使用这些标准，我是否会利用某些标准来locking自己？
我的“discover.php”文件的function类似于Web服务中的WSDL文件。我对REST的描述感到惊讶，似乎没有发现RESTful服务提供的服务的标准化方式，还是在那里？
如果一个客户端网站试图将一本书添加到服务器网站，并且没有得到任何“成功”的回应，那么只要再次尝试，直到得到回应。服务器网站将不会添加同一本书两次。这是我对REST中数据完整性的理解，难道还有比这更多的吗？
最终我想拥有多个具有相同丰富类的网站，例如“BookReview”，以便客户端网站能够执行如下所示的代码：

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

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

如果我不使用这些标准，我是否会利用某些标准来locking自己？

你自己locking了HTTP标准。当然，你可以使用GET参数来做同样的事情。这不仅仅是REST，而是RPC-Like。

我可以推荐Leonard Richardson和Sam Ruby的RESTful Web Services吗？阅读和显示不同方法之间的差异是相当有趣的。

要更详细地回答您的问题：由您决定走哪条路。从理论上说，你可以用RESTful和RPC类似的方法完成所有相同的工作。使用RESTful，您使用底层的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？
- 有HTTPauthentication。为什么要发明一个 – 可能不太安全的securityId？
- 顺便说一句：你不应该允许通过GET更改数据。这只是不应该做的事情（另一个话题，但;））

我build议你阅读Roy Fielding的这篇文章。

一个亮点：

REST API应该花费几乎所有的描述性努力来定义用于表示资源和驱动应用程序状态的媒体types，或者为现有标准媒体types定义扩展关系名称和/或启用超文本的标记。用于描述在感兴趣的URI上使用什么方法的任何努力应该在媒体types的处理规则的范围内（并且在大多数情况下已经由现有媒体types定义）完全定义。 [这里的失败意味着带外信息正在推动互动，而不是超文本]。
REST API不能定义固定的资源名称或层次结构（客户端和服务器明显的耦合）。服务器必须有自由来控制自己的命名空间。相反，允许服务器通过在媒体types和链接关系中定义这些指令来指导客户如何构build适当的URI，例如在HTML表单和URI模板中完成。 [这里的失败意味着客户端正在由于带外信息而假设资源结构，例如特定于领域的标准，这是面向数据的等价于RPC的function耦合的]。

您可以成功地使用类似于RPC的方法，并且比“正确的REST API”更容易掌握。 REST最令人误解的一个方面是，一旦定义，它应该自动工作 ，你不应该定义去这个URI使用这个方法来得到这个答案，这应该都是你正在提供的媒体types，加上一种手段让客户知道在哪里可以find相关的资源。

来自RestWiki ：

考虑到这一点，将它应用到你的应用程序应该是非常简单的。

通过Restlet框架，我们试图在HTTP细节之上提供这种抽象层次，并使REST概念更加具体化（许多人拥有类似组件，连接器和表示的匹配类）： http : //www.restlet.org/

我们是实用的编程人员，我们的用户使用RESTful框架（用于Java和GWT）开发真实世界的应用程序。 REST的支持者并不都是迂腐的，但是每种主要技术都有一条学习曲线。

我会试着看看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

REST是一个有趣且潜在有用的技术，但不幸的是它似乎吸引了最迂腐的开发人员。

看起来他们宁愿遵循REST教条的一个实现，即使这意味着完全丧失了function。任何偏离纯粹的REST将被视为异端。

我找不到有关REST的信息。对我来说，从networking极客的抽象angular度来看，它是一个很好的概念，不需要处理复杂的HTTP通信中涉及的更加严格的编码问题。

如果有一个REST API可以从所有的HTTP中抽象出来，会不会很好呢？但事实并非如此。相反，REST支持者必须完成一项销售工作，以便编写这样的API，以及所有伴随的debugging和testing问题。

当我看到一个REST 1.0头文件的时候，我会再看一下，find一个值得付出努力的优势。