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

Question

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

1. 谁能给我指点一些显示不同方法优缺点的文章方法？
2. 您能否就以下方法的优缺点分享您的想法？

建议的方法

1. 当用户在末尾添加 .xml 时，使用标准 Controller 返回 XML 网址的

   优点:

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

   缺点:

   • API 没有与主站点完全分离，更难维护
   • 人们可能会认为添加 .xml 会在它不起作用的地方起作用

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

   优点:

   • API 大部分是分离的
   • 仍然使用资源充足的 Controller

   缺点:

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

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

   优点:

   • API 完全分离
   • 如果我们不想，则不需要使用 Resource-full 样式
   • URL 清楚地表明它是一个 API，您应该查看文档以了解可用的内容(至少，我的思维方式是这样的；我假设其他开发人员的思维方式也是如此)

   缺点:

   • 更难使用来自网站代码的模型
   • 作为一个单独的项目更容易维护，但这意味着更难与现有网站
   • 必须保持代码库同步，因为模型可能会因站点功能/错误修复而改变

Answer 1

我建议 API 与您的网站在同一个项目中并不是一件坏事，只要代码是 DRY*。正如您所指出的，拥有单独的代码库是一个挑战，因为您必须使它们与您所做的每个功能/错误修复保持同步。如果它们在同一个地方，维护起来会更容易。只要您保持代码 DRY，此方法无疑是赢家。

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

只要我的 0.02 美元。

*DRY = 不要重复自己。 DRY 代码意味着您不会为您的站点和 API 复制粘贴或重写相同的东西；你从多个地方提取和调用。