Question

这就是我对REST架构的看法。

对于每个资源，都有一个唯一的URI。

我们可以使用它的URI和HTTP动作[POST，GET，PUT和DELETE]来操纵该对象。 HTTP请求传输该对象状态的表示。

在我读过的所有文本中，REST都以一种奇怪而混乱的方式解释。

另外一件事，rails中的RESTFUL实现为不同的目的产生不同的url。喜欢/团队 - ＆gt; 'index'方法... / teams / new - ＆gt;对于'新'方法等。这不是休息，它定义每个资源都有一个唯一的URI ???

Answer 1

我认为您对REST的理解非常好。它不需要比它应该更复杂。另外@Surya概述了一些非常好的观点。

Rails将HTTP方法映射到控制器方法的方式是：

GET    => show
PUT    => update
POST   => create
DELETE => destroy

rails提供的另外两个资源/方法是：

resource/new  => new
resource/edit => edit

很可能不是用于所有实际目的的资源，但是用于构建网页和应用程序是必需的。如果客户端完全了解资源，则不需要这些资源。客户端可以使用资源信息进行POST和PUT调用，并根据需要创建或更新资源。但由于不希望用户知道资源的来龙去脉，因此需要更简单的界面来创建或更新。

如果所有用户都完全了解资源并且熟悉命令行，我们甚至不需要HTML。他们只能curl与这些资源进行互动：）

index只是让您更轻松地使用集合。它仍然是一个定义良好的资源，并具有唯一的表示形式，例如/books。如何在服务器端代码处理它不会使它成为RESTless（我刚刚做了，但它很棒）。

Answer 2

我从Roy Fielding的论文的chapter 5开始。有几个基本原则：

资源：资源通常可以作为服务的一部分向外界公开。重点是识别资源（例如：Book，UserList，CalculateDistance）
URI：为每个资源提供一个标识符（例如：example.com/books/7654）
统一界面：使用GET，PUT等标准方法。 POST，DELETE，HEAD，OPTIONS
表示：资源可以有多个表示。例如，书上的GET可以返回该书内容的PDF，内容的HTML以及具有书籍封面等的GIF。表示本质上是所有数据和标记的集合。
超媒体：在我看来，这是一个非常重要的原则。这个原则的实现使您的应用程序远远领先于REST样式的常规CRUD定义。 HATEOAS是超媒体作为应用程序状态引擎的首字母缩写。当您单击链接或提交表单时，您正在更改应用程序的状态，这是通过超链接（或超媒体）进行的。服务器和客户端之间的耦合很少。客户端通过服务器提供的链接浏览应用程序。（在这个原则的博客圈中有很多讨论......）[另见Restfulie]

我最近answered a question有很好的资源来学习REST，可能会有所帮助。

我不熟悉Rails，所以不解决问题的这一部分。

Answer 3

这是我的REST基本概要。我试图展示RESTful架构中每个组件背后的思想，以便更直观地理解这个概念。希望这有助于为某些人揭开REST的神秘面纱！

REST（Representational State Transfer）是一种设计架构，概述了如何设计和寻址网络资源（即共享信息的节点）。通常，RESTful架构使得客户端（请求机器）和服务器（响应机器）可以请求读取，写入和更新数据，而客户端不必知道服务器如何操作以及服务器可以通过它不需要知道客户端的任何信息。好的，很酷......但我们在实践中如何做到这一点？

最明显的要求是需要某种通用语言，以便服务器可以告诉客户端它尝试对请求做什么以及服务器做出响应。
但是为了找到任何给定的资源，然后告诉客户端资源在哪里，需要有一种指向资源的通用方法。这是统一资源标识符（URI）的用武之地;它们基本上是查找资源的唯一地址。

但REST架构并没有就此结束！虽然上述内容满足了我们想要的基本需求，但我们还希望拥有一个支持高流量流量的体系结构，因为任何给定的服务器通常都会处理来自多个客户端的响应。因此，我们不希望通过记住有关先前请求的信息来压倒服务器。

因此，我们强加了客户端和服务器之间的每个请求 - 响应对是独立的限制，这意味着服务器不必记住有关先前请求的任何信息（客户端 - 服务器交互的先前状态））回应新请求。这意味着我们希望我们的互动是无国籍的。
为了进一步减轻我们的服务器上的压力，使其重做最近为给定客户端完成的计算，REST还允许缓存。基本上，缓存意味着拍摄提供给客户端的初始响应的快照。如果客户端再次发出相同的请求，则服务器可以向客户端提供快照，而不是重做创建初始响应所需的所有计算。但是，由于它是快照，如果快照尚未过期 - 服务器提前设置过期时间 - 并且响应自初始缓存以来已更新（即请求将给出与缓存响应不同的答案），客户端将不会看到更新，直到缓存过期（或缓存被清除）并且响应再次从头开始呈现。
关于RESTful架构的最后一件事就是它们是分层的。实际上，在讨论客户端和服务器之间的交互时，我们已经隐含地讨论了这个要求。基本上，这意味着我们系统中的每个层仅与相邻层交互。因此，在我们的讨论中，客户端层与我们的服务器层交互（反之亦然），但可能有其他服务器层帮助主服务器处理客户端不直接与之通信的请求。相反，服务器会根据需要传递请求。

现在，如果所有这些听起来都很熟悉，那么很棒。通过万维网定义通信协议的超文本传输协议（HTTP）是RESTful架构的抽象概念的实现（如果你是像我这样的OOP狂热者，则是REST类的一个实例）。在REST的这个实现中，客户端和服务器通过GET，POST，PUT，DELETE等进行交互，这些是通用语言的一部分，可以使用URL指向资源。

Answer 4

您可能会注意到有4个HTTP操作，但典型Web应用程序中的基本CRUD操作需要7个不同的操作。其中一些实际上没有做任何事情（如/new和:id/edit），因此与REST架构并行。此外，索引操作不会对资源起作用，而是作用于资源集合（因此也是唯一的URL）。

所以基本的4个HTTP动作映射到这样的资源：

GET地图展示 - ＆gt; get /teams/:id
PUT映射到更新 - ＆gt; put /teams/:id
DELETE maps to destroy - ＆gt; delete /teams/:id
POST有点例外，因为资源尚未存在，因此它映射到基础/teams

总结一下：每个资源都有自己独特的URL，而rails还为UI和收集目的定义了一些额外的URL。

Answer 5

喜欢/团队 - ＆gt;对于“索引”方法...... / teams / new - ＆gt;对于'新'方法等等上。这不是远离休息，它定义了每个资源都有一个唯一的URI ???

不，这不会脱离REST，因为就REST而言/teams和/teams/new是两种不同的资源。

REST架构究竟是什么以及如何在Rails中实现？

5 个答案: