我应该如何使用Rails 3.0创build一个REST API?

我似乎无法在Web上find有关在Rails中构buildREST API的不同方法的更多信息; 所以我有两个问题:

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

build议的方法

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

    优点:

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

    缺点:

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

  2. 使用名称空间路由来创build单独的API控制器,只处理API函数,但仍然可以访问网站使用的相同模型

    优点:

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

    缺点:

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

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

    优点:

    • API是完全分离的
    • 如果我们不想要的话,不需要使用资源丰富的样式
    • URL清楚地表明它是一个API,你应该检查文档以查看可用的内容(至less,我的思维是这样工作的;我假定其他开发人员的头脑也是这样)

    缺点:

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

我build议只要代码是DRY *,与您的网站在同一个项目中的API不是一件坏事。 就像你指出的那样,分离代码库是一个挑战,因为你必须保持它们与你所做的每个function/错误修正同步。 如果他们在同一个地方,则更容易维护。 只要你保持你的代码干,这种方法是明确的赢家。

我将提供来自控制器的XML和JSON与由Rails的路由引擎处理的子域。 当有人拿起api.site.com/resource.xml的模式,并试图访问不在那里的资源,这真的不是什么大不了的事情。 只要你的API被清楚地logging下来,当你尝试访问一个不在你的API中的资源时,你就会失败/错误,这应该会很好。 我会尝试返回一条消息,说该资源不可用,并为您的api文档的url。 对于任何API使用者来说,这不应该是一个运行时问题,因为这应该是发现你的API的一部分。

只是我的$ 0.02。

*干=不要重复自己。 干代码意味着您不要复制粘贴或重写您的网站和您的api相同的东西; 你从多个地方提取和调用。

我认为最好的解决scheme是合并你的前两点。

我build议使用JSON而不是XML:唯一有利于XML的是XPath,它在返回的数据中是无用的。 JSON导致更好的响应时间(以及更好的debugging更可读的数据!:p)。 另外,大多数语言都可以读取JSON。 例如,PHP可以使用json_decode本地parsingJSON到数组/对象,所以这是一个很好的观点。 ;)

对于控制器,你可以命名空间,但它不是一个义务,也许在某些情况下,避免有很多条件的胖行为更好。 使用Rails 3路由器,子域(api.webapp.com)中API调用的分离是微不足道的)。

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

新的rails路由器语法是糖,你会喜欢。 祝你好运,玩得开心! 🙂