#6 楼 @Saito Third-Party Web Widget 的难度确实挺大的，涉及到跨域请求、跨域消息传递、第三方 cookie、Embedding Iframe Style 等一系列棘手问题。但我觉得技术就是用来解决问题的，不写代码就可以搭建网站（利用网站的某个功能）是每个开发者都想要的啊。。

举个最简单的例子，一个大型网站的各个子网站都需要评论功能，花时间和精力开发一个好用的 Comment Web Widget 难道不值得么？同时也给其他项目节省了大量时间和资源。服务提供方作为一个平台，花一点精力去做些提升性能和易用性的工作是完全值得的。其实 Third Party Web Widget 也解决了 REST API 版本发布的最大难题，发布之后就要一直维护已有的接口，给升级带来痛苦。

做不好完全是吃力不讨好的行为。

任何事情做不好都是一样....

两者还有一个巨大差别，REST API 一定是官方提供的，而 Third-Party Web Widget 任何人都可以写。

Third-Party Web Widget 也必须 API 提供方自己域提供呀（因为涉及到 session 信息），除非是简单的 Proxy，才任何人都可以写。

#2 楼 @zlx_star 不会理他的.. #1 楼 @bhuztez

#3 楼 @Saito yes，Web API 的本质是让第三方以一个更灵活的方式利用服务方的资源。

Web API 也好，Third Party Web Widget（或 Third Part Javascript）也好，都是用来实现这个目的的手段。设计 API 的时候不应该考虑的是设计 REST API 还是 Third Party Web Widget，首先考虑的应该是第三方调用的方不方便。

Third-Party Web Widget 和普通 REST API 的界限不是很明显。比如一个返回 JSON 的 API 加一个 callback 立马就成立 JSONP 调用，就更 Web Widget 化了..

还有 S3 上传的例子，其实就是普通的 Web API，但却可以设计得很 Web Widget.

我想阐述的就是 API 应该离用户越近越好，如果可能的话，这是努力的方向。

#11 楼 @simlegate http://hooopo.iteye.com/blog/993538 稍微复杂一点的

#85 楼 @i5ting @jasl 怎么组

#22 楼 @ery 不用装在里面查源码也方便。并且平时只查 app 里的源码。特殊情况才查 gem 里的源码：

ack hello `bundle show --paths`

Bundler 的作用：依赖声明、自动解依赖、依赖隔离 Gemset 的作用：系统 gem 隔离

显然重复了，除非你要维护没使用 bundler 的项目。 说 Gemset 和 Bundler 没重叠的都在 Rails2 和 3 一起用么？即使 Rails2 也可以用 bundler。

good

http://ruby-china.org/topics/3224#reply3

#16 楼 @Saito 其实 dsl 语法差不多

• json.array! vs collection
• json.set! vs node
• json.extract! vs attributes

# app/views/users/show.rabl
object @user

# Declare the properties to include
attributes :first_name, :last_name

# Alias 'age' to 'years_old'
attributes :age => :years_old

# Include a custom node with full_name for user
node :full_name do |user|
  [user.first_name, user.last_name].join(" ")
end

# Include a custom node related to if the user can drink
node :can_drink do |user|
  user.age >= 21
end

#11 楼 @googya 所以要综合比较呀

#12 楼 @Saito 这样？

object false
node(:some_count) { |m| @user.posts.count }
child(@user) { attribute :name }

#8 楼 @Rei 按这种说法，最直观的是 to_json

#2 楼 @zgm 集成到 Rails4 里说明不了什么，一般用 json 模板都是做 API 服务器，Rails 做 API 服务器没有一点优势。

PS. rabl 支持 JSONP，这点符合我的胃口。

#2 楼 @zgm 作者都是大牛呀..

• rabl 作者是 padrino 的作者
• jbuilder 作者是 dhh
• active model serialiers 代码贡献最多的是 yahuda

看 star 数，群众的眼睛是雪亮的。

#10 楼 @luikore 其实我也有去他们的 public 项目上瞄了几眼..

1. 他们自己使用 basecamp + github
2. 但是也需要在 basecamp 上讨论代码相关问题：https://public.basecamp.com/1679267/projects/764604-bcx-phone-site/todos/30777675-failed-nameless
3. 他们几乎只用纯文本..
4. 上面链接里的所有代码都显得那么的碍眼

格式一多，经常会被误用，比如用标题来加粗，一行一个代码块，各种神奇的用法都有。格式最简化，注意力才会集中在内容。

我看到的是 Github 上热门项目的 README 和 WIKI 样式美观、描述清晰。 按这种思维纯文本才是最好的。就现在 basecamp 编辑器的几个功能，没有标题，我只能“滥用”加粗功能，根本没有阻止我。

我觉得这是有意为之的，功能越少越好。

这种结论显然站不住脚，Basecamp 的 feature 列表里可是列了 20+ 的功能.. 我只能理解为，编辑器不是他们的核心 feature, 但被人们当成编辑器的标准，这让人有些震惊。

#3 楼 @Rei

Basecamp 主要用途是设计师开项目的时候上传设计图，然后针对设计图评论，这个体验一级棒。

Basecamp 自己的描述是这样的：Basecamp is the leading web-based project management and collaboration tool. To-dos, files, messages, schedules, and milestones.

根本没有强调什么设计师，项目管理、协作工具的使用者既有设计师又有程序员。

是不是在 callback 里做了有外部请求的操作？比如发邮件、请求 API 之类。如果有，可以在 after_commit 后调用..

rack 2.0 https://gist.github.com/raggi/11c3491561802e573a47

#7 楼 @bhuztez 好吧..

#1 楼 @bhuztez nginx 把这东西打开的话就完蛋啦 这种自定义 header 有什么规范吗？

#3 楼 @luikore 有获取 raw data 的方法么？我一直以为应该有一个request.headers这样的方法，但是没找到..

#1 楼 @bhuztez thx!

#24 楼 @googya 该怎样？

自增 id 做主键是最佳实践，楼主就别瞎折腾了

（当前时间 - 2013 年）之间的秒数

有什么好处呢？并发插入了怎么办？

最活跃的人 == 水王