不要混用，就用 Rails。

可以参考 ruby-china 源码

如果你又要 api 又要 html view，我觉得就不要用 grape 了吧。。直接用 rails 的 json builder 吧= =controller 看上去会舒服很多。

ruby-china 可是有官方客户端的，这不是现成的吗

我们公司是 rails-api 写 api，web 端使用 reactjs + redux

建立前后分离，搞单页 APP

同样的业务逻辑需要在 Grape 和 Rails 里分别写一遍？ 你们逻辑难道在 controller 里面？

我在极客学院上看了 Grape 和 rails 的集成，感觉挺好的，但是为什么我感觉这么做，都要多写一次结构呢？

#7 楼 @zhang_soledad 是不是最好把逻辑卸载 model 里面？

@hewe active_record 是充血模型 逻辑都放在对应的领域模型里 只有在过于复杂跨多个领域模型的时候才会写 service 但是逻辑都不会写在 controller 里面

不要用 Rails，应该前后端分离

最近刚好用 Rails+Grape 重写了公司之前用 PHP 写的 API，个人感觉 Grape 写起来还是不错的，还可以用 Swagger-UI 搭建可视化页面;具体可以参考 http://baya.github.io/2015/04/03/grape-api-%E5%BC%80%E5%8F%91%E5%AE%9E%E8%B7%B5.html http://blog.elbowroomstudios.com/apis/ http://dev.classmethod.jp/server-side/ruby-on-rails/ruby-on-rails_create_grape_web-api/ 这些人的例子。

感谢各位！ 决定前后分离，Rails+Grape 做 API！

#5 楼 @jicheng1014 请问用 rails-api 怎么做请求参数的校验？

#14 楼 @numbcoder rails 怎么做 rails-api 就怎么做呗 rails-api 是一个简化版的 rails 去掉了大多数关于 view 层的东西 https://github.com/rails-api/rails-api 之后现在 rails-api 已经被 merge 到 rails 里了

直接基于 rails 的 controller 做 api 也挺好的，可以看 rubygems 的源码，doorkeeper 做 oauth2

#15 楼 @jicheng1014 rails 做参数验证大多放到 model 层，这放到 API-Only 的项目可能不太实用，特别是一些 GET 请求。

#17 楼 @numbcoder 不知道这些教条主义是怎么起来的。

每天使用的 rubygems.org api 就是个 Rails 项目。

#17 楼 @numbcoder 只看过简单 JSON API 项目的人很难理解 Parameter Validation and Coercion 的重要性

#17 楼 @numbcoder 为什么呢？

#18 楼 @rei 纯 API 项目和传统的 Web 项相比是有很大区别的，传统 web 项目可以自己控制请求参数，而且可以自己在页面用 JS 等方式验证数据格式。而 API 项目却不同，调用 API 的环境比较复杂，可能是 Web 端、移动端，或者是其他应用程序，这种情况下你就很难保证 API 的使用者在使用 API 时会先对参数进行严格校验，这种情况无论对于安全性还是服务器资源的利用都是不利的

举个最简单的登录的例子

user = User.find_by_email(params[:email])

如果不先对参数 email 进行校验，而实际上它是一个非法的 email 格式，那么这次数据库查询几乎就是浪费。 我说的这种情况在你所强烈推荐的 rubygems.org 项目中到处都是，所以我并不认为它是一个好的可以参考的例子！

关于 API 的设计，我推荐这篇文章 http://mp.weixin.qq.com/s?__biz=MzA3NDM0ODQwMw==&mid=208060670&idx=1&sn=ce67b8896985e8448137052b338093e0&scene=21#wechat_redirect

#19 楼 @42thcoder #20 楼 @pathbox

#21 楼 @numbcoder 在 Web 项目服务端也不相信请求的参数。

#22 楼 @rei Rails 的一个核心思想是 CoC，所以在比如访问 /users/:id 页面的情况下，我相信大部分人写代码不会去验证参数 id 是否是 Integer 类型，而是直接 User.find(params[:id])，原因在于，大部分情况下用户访问 /users/23 这个页面都是通过链接点进去的，而不是自己手动输入，这种情况下 id 不存在或者格式有误的情况非常少

#21 楼 @numbcoder Web 项目，浏览器输入的 param 一样需要严格校验的，否则被恶意请求搞出各种问题。

互联网应用的准则之一，就是不要相信任何外部的输入。

#18 楼 @rei rubygems.org 是 Rails 写的 API 项目就能证明 Rails 适合写 API 吗？我遇到的很多人都认为 Grape 比 Rails 更适合写 API。

#25 楼 @nouse 这些人 Rails 用得不够熟练。

#26 楼 @rei

Present any piece of real code and we can ping pong on it. I enjoy talking about specifics and improving real code.

#27 楼 @42thcoder https://github.com/rubygems/rubygems.org

一个成功例子还不够？我倒没看见说 Grape 比 Rails 好有实例的。

Grape 跟 Rails 有个失败例子，之前 Ruby China 有个权限漏洞，原因是 Grape 跟 Rails 过滤参数不一致，导致 Mongodb 注入。

#28 楼 @rei 这是一个"成功"的例子么？我看出不来。麻烦举个 rubygems 项目里面的 ( 需求 ) 复杂 API 吧

#29 楼 @42thcoder 不成功你可以不用啊。让你觉得这个 API 很简单就是他们写得好。

#23 楼 @numbcoder 不知道你为何这么想，我猜你之前是写 java 或者 c++ 的。

#31 楼 @embbnux 呵呵 难道你觉得验证参数是很愚蠢的行为吗？

#17 楼 @numbcoder 额 我好像没 get 到你这的点呢。

校验是放在 model 里的，当然你要在 action 里做一次校验，没什么不好的。如果你是怕多查数据库的话，你可以加个 redis 限制 api 的访问就好了

我们的 rails 项目就是纯 api 的，效果还行

#32 楼 @numbcoder 楼上正解

#30 楼 @rei ¯_(ツ)_/¯

#33 楼 @jicheng1014 说来说去都说得很虚，我举一个现实的场景吧：

需求

前端需要订单列表接口，根据属性做过滤，GET admin/orders.json .

订单的 schema 我们简化为：

#  title           :string(255)
#  code            :string(64)       not null
#  id              :integer          not null, primary key
#  state           :string(255)

产品的需求

• 只允许查询状态是已结束和已关闭的 ( %w(closed done).include? state ), 后期随时扩展，默认是 closed
• 如果要根据标题做查询，一定要填写编码。( code 和 title 两个参数要么都不传，要么一起传 )

前端开发和后端开发的约定：

• 每页最多只能取 200 条记录 ( per_page < 200 )
• id 一定要是整型，不允许 undefined

Grape 的做法

Grape 提供了一套 DSL 来做 Parameter Validation and Coercion. 上面的需求可以这样做：

params do
  optional :title, type: String, desc: '标题'
  optional :code, type: String, desc: '编码'
  optional :id, type: Integer, desc: 'ID'
  optional :state, type: String, values: %w(closed done), default: 'closed', desc: '状态'
  all_or_none_of :state, :code

  use :pager_params
end

Bonus

借助 Swagger, 上面那段代码可以转化为前端友好的文档。live demo: http://petstore.swagger.io/

Rails 的做法

裸写，具体位置可以放在 controller, 也可以放在 model 层。当然作为一个 Rails 用得不够熟练的码弱，还期待 LS 的指教。

Let's ping pong~

#33 楼 @jicheng1014 #34 楼 @embbnux Post/Put 的请求是可以放在 model 层检验，Get 请求的参数你们都不校验对吧？ 我所强调的是安全性和性能，尽量把事情做到极致，如果你们觉得这两个都无所谓，那就争的没啥意思，毕竟价值观不一样。

#30 楼 @rei 请不要再拿 rubygems.org 这个项目为例来误导别人了，我前面已经举例说明了，它为什么不是一个好的例子

我说「吸烟有害健康」，你们却反驳说「张学良吃喝嫖赌活到了 103」，那我只能呵呵了

接 #34 楼 @42thcoder 的例子，我再来举一个 Get 请求，不验证参数导致的安全性问题

我曾经见过不少新手都是这么写的 API 的原本意图是是可以按 created_at 或 updated_at 排序来取数据

# PostsController
def index
  @posts = Post.order("#{params[:sort]} #{params[:order]}")
end

如果 API 的调用者，故意给 sort 参数传了一个未加索引的字段，或者是一个 text 类型的字段，可以看看你们的数据库还能撑多久

#35 楼 @42thcoder @numbcoder 说来惭愧，我们的项目在 get 的时候大多数情况没在查询之前做参数验证，觉得我们开放出来的查询都会有索引，所以传错值问题引起的性能损失不大。主要考虑的还是安全问题，比如不做校验，会带来哪些安全上的风险呢？

#37 楼 @numbcoder 这种写法肯定是不科学的

#35 楼 @42thcoder 这个帖子不错，讨论示例最直观。

感觉是各有所长啊。grape 可以不用写文档。

如果没有 web 单纯用 Rails 写 API 有点大炮打蚊子的意思，@rei 老大说那是你大炮用得不好 😊。个人认为 grape 简单，足够应付 API，楼上提到的参数验证还有结合 swagger 也是极好的。而 Rails 是个臃肿的 web 架构（原谅我不懂给它瘦身）Ruby 被“慢骂”的原因不正好是太多的误用吗，足够简单才好去避免误区。

#37 楼 @numbcoder #38 楼 @jicheng1014 根据 id 或者根据 email 来查找，通过验证格式来减少数据库查询，这个是否要做，完全看项目需求和编码规范。

但是 order by 或者其他查询直接依赖传入参数如果不做校验的话，不单单是潜在的性能 DDOS 问题，还有 sql 注入问题，这不是新手的问题，或者说是 rails、grape 的选择依据，完全是因为没有意识到这里的安全问题导致

#43 楼 @quakewang 我问大家 Rails 如何方便的做参数校验时，有人觉得我是奇葩，为什么会有这种想法，所以我才举出上面的例子。我并不是说 Rails 有安全性问题，我只是说大家很容易忽略 Get 请求的参数验证，事实上在 Rails 里做请求参数验证就是很不方便，上面已经有人举例子了。

#35 楼 @42thcoder RESTful api 关于 create/update api 数据校验是在 model 做的，关于 read/delete by id，这个并没有什么可说的。

你举的关于复合查询 api，我通常会选择引入 ranksack ( https://github.com/activerecord-hackery/ransack ) ，然后写一个 hash 的 filter 扩展方法，用起来是这样：

params.ransack_filter!(title: :cont, code: :eq, id: :eq, state: {predicate: :eq, values: [:closed, :done]})
Order.search(params)

不过不满足你例子里面的 dsl all_or_none_of，需要再做一些扩展，和 grape 的 dsl 相比，缺点是文档和代码不同步，优点是 2 行代码可以搞定（包括查询）

#43 楼 @quakewang 赞你的说法，不知道楼主在喷什么，也不能因为前面有参数验证就这么写，order("#{params[:sort]} #{params[:order]}") 这种不能容忍

#47 楼 @embbnux 用 46 楼提到的 rails_param ，我就这样写

def index
  param! :sort, String, in: %w(created_at updated_at), default: "created_at"
  param! :order, String, in: %w(asc desc),  default: "asc"

  @posts = Post.order("#{params[:sort]} #{params[:order]}")
end

请教一下能忍的写法是怎样的？

#48 楼 @numbcoder 我说的是尽量避免拼接 sql, 你这边 order 需求要那么多种情况的话，也只能这样。不过因为 order 的类型也就那么几个，用 include 是可以完全防住，其他的难道都能用 include 防住？最好还是这样 User.find_by(email: params[:email])

这个问题我一开始也纠结过。先分享下我现在的用法和项目背景 因为是纯 API 服务，所以

1. API 使用 grape on rack 的方案，自己加一些配套的 gem 来完成类似 rails 的工具链
2. 使用 rails 开发 admin

对于你这个的问题。我的想法是这样的： 分析 API 和 web 的比重，如果 API 比较多，超过 80%，那么我建议用 grape，只是 on rails 还是 on rack，这个再根据性能要求去分析，其实一般要求的并发 rails 完全可以 hold 住。要求再高的可以用 on rack。 如果 web 超过 80%，那么肯定是用 grape on rails 或者 rails 的方案更合适

我认为，grape 在写 API 方面比 rails 裸写或者 rails_param 的方式肯定是更优雅的，也更合适做 API 的服务。如果 API 比重大那么就可以考虑引入。对比到学习成本和开发受益，应该是会有收获。

关键还是用合适的工具去做合适的事情，这么一个宗旨

最后引用一个老帖算是抛砖引玉吧 https://ruby-china.org/topics/9765

我们最近的项目用 Rails Metal 结合 jbuilder 做 API，Rails 做后端的 CMS，感觉比用 grape 用得舒服多了。

@numbcoder 明白你的意思，单纯来讲只是觉得你给的例子很不靠谱，类似 email, CID, phone 这种验证完全可以通过 rails validation 来处理而且并不会产生查询，再者这种新手写的这种 query 做法 (stupid) 跟上面讨论的（选谁或者是否校验）优劣性是 2 个问题。

Grape 很好用，只是集成在 rails 中时，会调用一些没有用到的 rails 中间件，不过这个性能消耗可以接受，主要是要做好缓存

其实 Grape 那个 params 验证还是挺需要的，Ruby China 重新基于 Rails API 来改写了 API 以后，还是自己实现了一个类似的 params 验证机制（预言未来 Rails API 会自带这样的功能）

https://github.com/ruby-china/ruby-china/pull/612

然后再说 Grape 那种自动生成文档，其实也是看起来很美，还是太粗糙了，尤其是你没法写太多例子，不然代码里面全是一大堆一大堆的注释了，真正大型复杂的项目还是得用 https://apiary.io 这类工具。

写 rails-api 的时候用到过 apipie-rails(GitHub) 这个 gem, 参数验证和简单的文档生成都能胜任。

#55 楼 @karloku 试过，不好用，放弃了

看了这么多讨论貌大家都没有回复：是不是意味着同样的业务逻辑需要在 Grape 和 Rails 里分别写一遍？或者干脆 WEB 端也前后分离，直接调用 API？其实我也想知道答案，另外如果 web 和 app 项目只有 60% 业务逻辑可以公用又该如何选择呢？

#57 楼 @jayliud 当然不能都写一遍，我的做法是写一个 gems 然后封装这些 model，还在探索。

#58 楼 @ericguo 所以呼唤有此类项目经验的人来做些分享，不要抓着参数验证这块不放。。。业务逻辑移动和 web 即使同一个业务也可能有细微的不同

#48 楼 @numbcoder 这个写法不能容忍吗？ 看不出有什么危险啊

#8 楼 @hewe 你看的是不是我讲的课

就我的经验来讲，这种项目都是用 rails 来做 web，grape 挂载上去做 api，不存在同样的逻辑做 2 次，因为业务逻辑大部分都是做在 model 这一层，web 层和 api 的层的业务大多数情况不是完全一样的。而且 web 这一层验证一般用 cookie 做，而 api 这一层用 cookie 不是一个好的 practice，所有感觉还是分开比较好，也为你以后拆分成不同的模块做准备

#61 楼 @sufish 对的，哈哈，大神好。☺

学习了，菜鸟进来膜拜一下