我想请教下大家一个 Rails App 架构的问题：
这个 App 有两个大的角色：1）iOS 及 Android 的 API server。2）网站。
就我目前了解的知识而言，就算是对同一个 model，这两个角色的处理逻辑差别也是非常大的，比如：对 User 这个 model 的处理，同样是创建 user（UsersController::create)，网站这个角色创建完了 user，可能就重定向到 user 的 profile 页面了，而 API server 这个角色创建 user 之后，可能仅仅返回一些必要的数据就可以了，并不需要重定向。
所以，架构上来讲，数据库应该是用同一个。我的问题是：controller 应该用同一个么，例如在 UsersController 的 create 方法中通过对不同 format 的判断，从而提供不同的 response。这样处理会不会显得逻辑很复杂？还是说即使是对同一个 model 的处理，也应该根据这两个角色分两个不同的 controller？
多谢！
分开写，移动端的放入 api。web 端的用本身的 controller。注意哦，web 端和移动端从哪里拿数据，并不一定非得依赖 scaffold 弄出来的 controller。 另外：api 方便测试，web 端的测试逻辑和移动端不同，写在一起就是自找麻烦了。
第一步还是写 API 和 Web 在一起好点。没必要搞那么大，想那么远。谁知道半年之后你们项目还是不是继续干。先实现功能为主。 对于 Controller 来说，API 和 Web 端要分开放在不同的文件中。
建议还是分开，我们现在的架构给你参考，一个 sinatra 的 app mount 在 Rails 上做 API，登陆专门拿出去做了一个单独的 sinatra service
我的问题是： 1.controller 应该用同一个么，例如在 UsersController 的 create 方法中通过对不同 format 的判断，从而提供不同的 response。 否。就像上面说的，分开架 API。推荐 Grape
2.这样处理会不会显得逻辑很复杂？ 一点点，不过架构比较清晰。遵循 fat model, skinny controller 的原则
3.还是说即使是对同一个 model 的处理，也应该根据这两个角色分两个不同的 controller？ 有点麻烦，不太推荐。
