我是Rails 3的新手,我试图理解以RESTful方式设计应用程序的优势 . 我不需要API / Web服务 . 不需要XML或JSON .
我正在构建的应用程序根本不使用CRUD . 它是一个通过套接字连接收集交易数据并以多种不同方式显示给用户的应用程序 .
我想以不同的方式想象交易,例如:
-
最近
-
最高产量
-
各州的贸易
-
最活跃的交易
_0009亿美元的交易 -
作为一般义务债券的交易
-
等......
在“Rails方式”中,我似乎会有一个非常重载的索引操作 . 或者我可以反对约定,只是在交易控制器中创建方法,如most_recent,highest_yielding,most_active等 . 但这似乎违背了在Rails 3中设计应用程序的整个哲学 .
看起来Rails中RESTful方法背后的想法是基于CRUD的,并且当不涉及CRUD时就会失败 . 除了遵循惯例之外,将应用程序设计为“RESTful”真的有优势吗?我真的没有看到这里的优势 .
另外,如果我确实需要API,我会想到设计一个带有API的API要好得多 . 我的API不是我的网站的直接1对1匹配,它是为人类消费而不是机器而构建的 .
我很欣赏这方面的任何见解 . 也许我在这里遗漏了一些东西?
3 回答
当涉及资源时,实际上涉及CRUD . 而且由于几乎每个应用程序都有资源可以参与CRUD,并且通常(如果你问我),这是最好的方法 .
这个想法是资源有某些行动 . 您可以查看资源,编辑资源,删除资源等等 . 像most_recent(或这个范围)的方法应该在模型而不是控制器中使用 . 然后,如果您需要使用该集合,您只需调用以下内容:
在你的控制器中 . 您的控制器不应该有太多代码,实际上根本没有业务逻辑 .
RESTful非常好,因为它自然地处理资源 . 控制器实际上应该处理资源 . 如果您认为可以编辑或创建某些内容,则应由控制器处理 .
一般来说,我强烈建议你深入了解一下,你肯定会看到自己的优势 .
我知道该怎么做 . 代码未经过测试,我只是在没有运行的情况下编写它 .
控制器:
模型
视图
您的设计应始终首先考虑您的应用程序的要求和框架的哲学 .
如果哲学不符合您的要求或您认为是开发应用程序的最佳方式,那么要么忽略它,要么,如果框架使您难以像您认为的那样构建(这不是在Rails imho中的情况),切换到另一个框架 .
所有这些都没有't have much to do with REST. For more info on why REST is considered a good idea (for some, not all, things), see the following SO Q&A':Why would one use REST instead of Web services和What exactly is RESTful programming .