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

Question

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

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

 

提议的方法

 

1. 当用户添加.xml到URL的末尾时,使用标准控制器返回XML

   优点:

   • 这是内置于Rails并且非常易于使用
   • 遵循Rails所具有的基于资源的方法,因此现有用户很容易理解/记住

   缺点:

   • API与主站点没有干净的分离,难以维护
   • 人们可能会认为添加.xml将在它没有的地方起作用

2. 使用命名空间路由创建单独的API控制器,这些控制器仅处理API函数,但仍可访问网站使用的相同模型

   优点:

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

   缺点:

   • URL的格式为site.com/api/resource.xml,这可能会使人们认为所有资源都可用
   • API仍然是网站代码/项目的一部分; 因此,更难维护

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

   优点:

   • API完全分开
   • 如果我们不想要,则不需要使用资源完整样式
   • 网址清楚地显示它是一个API,您应该检查文档以查看可用的内容(至少,我的思维方式是这样做的;我假设其他开发人员的想法也是如此)

   缺点:

   • 更难使用网站代码中的模型
   • 作为单独的项目更容易维护,但这意味着更难与现有站点集成
   • 必须保持代码库同步,因为模型可能会因站点功能/错误修复而发生变化

Answer 1

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

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

只需我0.02美元.

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