这就是我对REST架构的看法.
对于每个资源,都有一个唯一的URI.
我们可以使用它的URI和HTTP操作[POST,GET,PUT和DELETE]操纵该对象. HTTP请求传输该对象的状态的表示.
在我阅读的所有文本中,REST以一种奇怪而令人困惑的方式解释.
另外还有一件事,在rails中的RESTFUL实现为不同的目的生成不同的URL.喜欢/团队 – > for’index’方法… / teams / new – >为’新’方法等等.这是不是离开休息,这定义每个资源有一个唯一的URI？
解决方法
我认为你对REST的理解是相当不错的.它不需要比它应该更复杂.另外@Surya概述了一些非常好的点.
GET => show PUT => update POST => create DELETE => destroy
轨道提供的另外两种资源/方法是：
resource/new => new resource/edit => edit
很可能不是所有实际用途的资源,但是构建网页和应用程序是必需的.如果客户对资源有完全的了解,那就不需要了.客户端可以使用资源信息进行POST和PUT调用,并根据需要创建或更新资源.但是,由于用户不期望知道资源的内在和外部,因此需要一个更容易的界面来进行创建或更新.
如果所有用户完全了解资源,并且熟练使用命令行,我们甚至不需要HTML.他们可以卷曲在与这些资源的交互中:)
索引只是使它更容易使用集合.它仍然是一个明确定义的资源,并具有独特的表示,例如/书.如何在服务器端代码处理不会使它无法使用RESTful(我只是做了,但它的真棒).