靠自己顶一个吧

别把 PC 和 mobile 浏览器看得差别太大。对大部分应用来说只要分别渲染不同的 view templates 就可以了。如果 mobile 端是非浏览器而是 app，则用 json api 对应。

#2 楼 @ashchan 移动端指 app，客户也好网络环境也好现在大部分还是要 app（web 页面的话直接考虑 html5 加 css 做兼容了）。 给 app 做了一套接口和逻辑供调用，也需要 web 页面时用 rails 做里面的 model 等逻辑再写一遍有点浪费，rails 里面再调用 api 走两次网络请求的响应时间会否可接受，主要是这个：）

rails 里面再调用 api 走两次网络请求

弱问为啥会有两次网络请求呢，不是就一个 json 么……

#4 楼 @aptx4869 用户访问页面从浏览器到 rails，rails 数据通过网络从 api 获取（非 model 直接取数据库）

#5 楼 @as181920 有点不明白，弱弱得问下，为啥不能直接在 controler 里 respond_to :html, :json 呢…… 将 api 分离出来有啥特别的好处么？

#6 楼 @aptx4869 1，专门做 api 不需要 rails 加载那么多东西；2，rails 工程如果做不好响应速度慢了会直接影响到接口的效率；3，页面和 api 混在一起在工程很大的时候维护不容易。

主要是效率，前面手上一个项目从老的维护过来已经感觉响应比较慢，项目比较臃肿，里面再掺杂 api 进去效率不高也不易维护。

@aptx4869 api 的 action 和 web 端的 action 在大部分情况下需要不同的处理。如果将这些不同处理的代码都写到 controller 里面会让 controller 的代码很臃肿很丑陋，如果将 api 的处理代码抽离出来，controller 的代码就会清爽很多。
@as181920 grape 可以集成到 rails 里，非常方便的，你可以用 rails 写管理系统，然后 api 方面单独由 grape gem 处理.grape 搭配 grape-entirty 使用，基本上手机 app 的功能都能搞定，而且代码会很清爽，具体的资料可以在 ruby-china 搜索一下 grape，之前有大大们讨论过 grape
protobuf 是 google 的数据包格式，优点是数据压缩后比 json 数据包的大小小很多，而且有很多语言的代码版本，集成起来很方便。
thrift 是 facebook/apache 的数据包格式，与 protobuf 不同的是可以用它来写 RPC,protobuf 有 RPC 的接口，但是没写实现代码. 通常对于需要大量处理网络数据的应用 (网络游戏) 这些压缩量还是可观的。想象一下如果网络游戏用 json 或者 xml 来传输数据，数据包大小会大 20 倍左右，对于实时性要求高的射击游戏来说，这 20 倍的数据量的增加是致命的，而 web 应用则没有游戏那么苛刻的要求，故很少使用这些数据包格式

#3 楼 @as181920 建议倒过来，业务逻辑等在公用的 model 和 service 层提供（比方抽成一个 gem），api 和 web 直接消费这一层。设计和实现上，把 api 和 controllers 放在同等层次。

#8 楼 @sailtsao

api 的 action 和 web 端的 action 在大部分情况下需要不同的处理。如果将这些不同处理的代码都写到 controller 里面会让 controller 的代码很臃肿很丑陋

还是没弄懂……也许会是这样，但是我问的是 LZ 说的第三种情况，

pc 和移动都用这个 api

如果 pc 和移动端都用同一个 api，为啥还需要不同的处理……

#9 楼 @ashchan 这是个好的方法，我得花点时间考虑下具体怎么抽怎么实现，Thx。

若不考虑现有 rails 系统很慢的问题，直接在 controller 目录下建一个子目录叫 api，然后在其中定义 v1 版的 api，v2 版的 api…

#12 楼 @keating 以前是这么干的，方便；现在是以 api 为主，web 为辅，api 多且大，所以考虑要另外的设计。