>有人可以指点我的一些文章，显示不同的利弊
方法？
>请您分享您对以下方法的利弊的看法？
建议方法
>当用户将.xml添加到结尾时，使用标准控制器返回XML
的网址
优点：
>这是内置的Rails和非常容易使用
>遵循Rails具有的相同的基于资源的方法，所以它很容易
现有用户了解/记住
缺点：
> API与主站点不完全分离，难以维护
>人们可以假定添加.xml将在不它的地方工作
>使用命名空间路由创建仅处理API的单独的API控制器
功能，但仍然可以访问与网站使用的相同型号
优点：
> API大多是分开的
>仍然使用资源完全控制器
缺点：
> URL具有site.com/api/resource.xml的形式，这可能使人们承担所有
资源可用
> API仍然是网站代码/项目的一部分;因此，更难维护
>使用路由转发和约束将所有API调用转发到机架
应用
优点：
> API完全分离
>不需要使用Resource-full样式，如果我们不想
>网址清楚地显示它是一个API，您应该检查文档以查看可用的
(至少，我的心灵这样工作;我认为其他开发人员也这样)
缺点：
>从网站代码更难使用模型
>更容易维护作为一个单独的项目，但这意味着更难以整合
现有网站
>必须保持代码库同步，因为模型可能会因网站功能/错误修复而改变
我将提供XML和JSON从控制器与Rails的路由引擎处理的子域。当有人选择api.site.com/resource.xml的模式并尝试访问不在那里的资源时，这真的不是什么大问题。只要你的API文件清楚，你失败/错误优雅地，当他们尝试访问资源不在你的API，它应该是很好。我会尝试返回一个消息，说资源不可用和一个url到你的api文档。这不应该是任何API使用者的运行时问题，因为这应该是发现您的API的一部分。
只是我的$ 0.02。
* DRY =不要重复自己。 DRY代码意味着你不要为你的网站和你的api复制粘贴或重写同样的东西;您从多个地方提取和调用。
