REST架构究竟是什么以及如何在Rails中实现？
这就是我对REST架构的看法。
对于每个资源，都有一个唯一的URI。
我们可以使用它的URI和HTTP动作[POST，GET，PUT和DELETE]来操纵该对象。 HTTP请求传输该对象状态的表示。
在我读过的所有文本中，REST都以一种奇怪而混乱的方式解释。
还有一件事，rails中的RESTFUL实现为不同的目的产生不同的url。 喜欢/团队 – >’索引’方法… /球队/新 – >’新’方法等等。 这不是rest，它定义每个资源都有一个唯一的URI ???
我认为你对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 （我只是做了那个，但它真棒）。
我将从罗伊菲尔丁论文的第5章开始。 有几个基本原则：
- 资源：资源通常可以作为服务的一部分向外界公开。 重点是识别资源（例如：Book，UserList，CalculateDistance）
- URI：为每个资源提供标识符（例如：example.com/books/7654）
- 统一接口：使用GET，PUT等标准方法。 POST，DELETE，HEAD，OPTIONS
- 表示：资源可以有多个表示。 例如，书上的GET可以返回该书内容的PDF，内容的HTML，甚至是带有书籍封面的GIF等等。 表示本质上是所有数据和标记的集合。
- 超媒体：在我看来，这是一个非常重要的原则。 这个原则的实现使您的应用程序远远领先于REST样式的常规CRUD定义。 HATEOAS是超媒体作为应用程序状态引擎的首字母缩写。 当您单击链接或提交表单时，您正在更改应用程序的状态，这是通过超链接（或超媒体）发生的。 服务器和客户端之间的耦合很少。 客户端通过服务器提供的链接浏览应用程序。 （在这个原则的博客圈里有很多讨论……）[另外看看Restfulie ]
我最近回答了一个关于学习REST的良好资源的问题 ，可能会有所帮助。
我不熟悉Rails，所以不解决问题的这一部分。
这是我的REST基本概要。 我试图展示RESTful架构中每个组件背后的思想，以便更直观地理解这个概念。 希望这有助于为某些人揭开REST的神秘面纱！
REST（Representational State Transfer）是一种设计架构，概述了如何设计和解决网络资源（即共享信息的节点）。 通常，RESTful架构使得客户端（请求机器）和服务器（响应机器）可以请求读取，写入和更新数据，而客户端不必知道服务器如何操作并且服务器可以通过它无需了解客户端。 好的，很酷……但是我们如何在实践中做到这一点？
-
最明显的要求是需要某种通用语言，以便服务器可以告诉客户端它正在尝试对请求做什么以及服务器做出响应。
-
但是为了找到任何给定的资源，然后告诉客户端资源在哪里，需要有一种指向资源的通用方法。 这是统一资源标识符（URI）的用武之地; 它们基本上是查找资源的唯一地址。
但REST架构并没有就此结束！ 虽然上述内容满足了我们想要的基本需求，但我们还希望拥有一个支持高流量流量的体系结构，因为任何给定的服务器通常都会处理来自多个客户端的响应。 因此，我们不希望通过记住有关先前请求的信息来压倒服务器。
-
因此，我们强加了客户端和服务器之间的每个请求 – 响应对是独立的限制，这意味着服务器不必记住有关先前请求（客户端 – 服务器交互的先前状态）的任何内容以响应新的请求。 这意味着我们希望我们的互动是无国籍的。
-
为了进一步减轻我们的服务器上的压力，使其重新为最近为给定客户端完成的计算，REST还允许缓存。 基本上，缓存意味着拍摄提供给客户端的初始响应的快照。 如果客户端再次发出相同的请求，则服务器可以为客户端提供快照，而不是重做创建初始响应所需的所有计算。 但是，由于它是快照，如果快照尚未过期 – 服务器提前设置过期时间 – 并且自初始缓存以来响应已更新（即请求将给出与缓存响应不同的答案） ，客户端将不会看到更新，直到缓存过期（或清除缓存）并且响应再次从头开始呈现。
-
关于RESTful架构，您经常会遇到的最后一件事是它们是分层的。 实际上，我们在讨论客户端和服务器之间的交互时已经隐含地讨论了这个要求。 基本上，这意味着我们系统中的每个层仅与相邻层交互。 因此，在我们的讨论中，客户端层与我们的服务器层交互（反之亦然），但可能还有其他服务器层可帮助主服务器处理客户端不直接与之通信的请求。 相反，服务器会根据需要传递请求。
现在，如果所有这些听起来都很熟悉，那么很棒。 通过万维网定义通信协议的超文本传输协议（HTTP）是RESTful架构的抽象概念的实现（如果你是像我这样的OOP狂热者，则是REST类的一个实例）。 在REST的这种实现中，客户端和服务器通过GET，POST，PUT，DELETE等进行交互，这些是通用语言的一部分，并且可以使用URL指向资源。
您可能会注意到有4个HTTP操作，但典型Web应用程序中的基本CRUD操作需要7个不同的操作。 其中一些实际上没有做任何事情（比如/new和:id/edit ），因此与REST架构并行。 此外，索引操作不会对资源起作用，而是作用于资源集合（因此也是唯一的URL）。
所以基本的4个HTTP动作映射到这样的资源：
- GET地图显示 – >
get /teams/:id - PUT映射到更新 – >
put /teams/:id - DELETE映射到destroy – >
delete /teams/:id - POST有点例外，因为资源尚未存在，因此它映射到基础
/teams
总而言之：每个资源都有自己独特的URL，而rails还为UI和收集目的定义了一些额外的URL。
喜欢/团队 – >’索引’方法… /球队/新 – >’新’方法等等。 这不是rest，它定义每个资源都有一个唯一的URI ???
不，这不会脱离REST，因为就REST而言， /teams和/teams/new是两种不同的资源。