我应该如何使用Rails 3.0创建REST API？

Question

我似乎无法在网上找到有关在Rails中构建REST API的不同方法的更多信息;所以我有两个问题：

1. 有人能指出一些显示不同的利弊的文章 方法吗
2. 请您分享您对以下方法的优缺点的看法？

提议的方法

1. 当用户将.xml添加到结尾时，使用标准控制器返回XML  网址

   优点：

   • 这是内置于Rails并且非常易于使用
   • 采用与Rails相同的基于资源的方法，因此很容易实现 现有用户理解/记住

   缺点：

   • API未与主站点完全分离，难以维护
   • 人们可能会认为添加.xml会在不适用的地方发挥作用

2. 使用命名空间路由创建仅处理API的单独API控制器  功能，但仍然可以访问网站使用的相同模型

   优点：

   • API主要是分开的
   • 仍然使用资源完整控制器

   缺点：

   • 网址的形式为site.com/api/resource.xml，可能会让人们假设全部 资源可用
   • API仍然是网站代码/项目的一部分;因此，更难维护

3. 使用路由转发和约束将所有API调用转发到Rack  应用

   优点：

   • API完全分离
   • 如果我们不想
   ，则不需要使用资源完整样式
   • 网址清楚地表明它是一个API，您应该检查文档以查看可用的内容 （至少，我的思维方式是这样做的;我假设其他开发者的思想也是如此）

   缺点：

   • 更难使用网站代码中的模型
   • 作为单独的项目更容易维护，但这意味着更难集成 现有网站
   • 必须保持代码库同步，因为模型可能会针对网站功能/错误修复进行更改

Answer 1

我建议API与您的网站在同一个项目中并不是坏事，只要代码是DRY *。就像你指出的那样，拥有单独的代码库是一个挑战，因为你必须让它们与你所做的每个功能/ bug修复同步。如果它们在同一个地方，它们更容易维护。只要你保持你的代码DRY，这种方法就是明显的赢家。

我会从控制器提供XML和JSON，其子域由Rails的路由引擎处理。当有人接受了api.site.com/resource.xml的模式并尝试访问不存在的资源时，这真的不是什么大问题。只要您的API被清楚地记录下来并且当他们尝试访问不在您的API中的资源时您会失败/错误，那么它应该没问题。我会尝试返回一条消息，说明资源不可用，以及您的api文档的URL。对于任何API使用者而言，这不应该是运行时问题，因为这应该是发现API的一部分。

只需我0.02美元。

* DRY =不要重复自己。 DRY代码意味着您不会为您的网站和api复制粘贴或重写相同的内容;你从多个地方提取和打电话。

Answer 2

我认为最适合您的解决方案是合并您的前两点。

我建议使用JSON而不是XML：支持XML的唯一一点是XPath，它在返回的数据中是无用的。 JSON可以提供更好的响应时间（以及更可读的数据，以便更好地进行调试！：p）。此外，大多数语言都可以读取JSON。例如，PHP可以使用json_decode本地解析JSON到数组/对象，所以这是一个很好的观点。 ;）

对于控制器，你可以命名它，但它不是一个义务，也许在某些情况下更好地避免大量条件下的胖动作。使用Rails 3路由器，子域（api.webapp.com）中API调用的分离是微不足道的。

对于模型，请确保使用与整个应用程序中使用的相同的内容。

新的rails路由器语法是糖，你会喜欢。祝你好运玩得开心！ ：）