#4 楼 @lyfi2003 是我们公司自己的云服务，这些都不能用。

之前只有人用 Ruby 封装了一层基本的 HTTP 请求，可以将文件传上去，并没有专门的 carrierwave 的 gem 包。

#1 楼 @Rei 那可以自己使用 carrierwave 保存到服务器端，然后再调用接口 post 到云端。这个流程没问题吧？

#2 楼 @tony612 客户端可能有体积要求，所以想放在服务器端做。我确实搜索到一些解决方案就是交给服务器端做的。

#1 楼 @huacnlee 好的 懂了。 #2 楼 @xiaoronglv 感谢，这个说的是耗时，但似乎没有提到内存占用。

@lgn21st

不是同一个项目，但是我自己的项目在本地开发环境从没有看到过前面还会加前缀的控制台输出信息。 很有可能是你说的这个哎。

最近在看 java spring，你看他的 guides 上第一篇的标题就是Building a RESTful Web Service https://spring.io/guides

@jasl 谢谢，最后也是用类变量@@status解决的，由于只有 1 个用户（也就是测试程序），连 hash 结构都没用，直接在第一个 action 中根据 post 请求传过来的参数赋值给@@status。

在第二个 action 中取出@@status就好。

感觉挺傻的方法～

@jasl 尝试了一下用 session 存储，默认是存 cookie 中，结果由于项目连前端 view 层都没有，用 postman 调接口测试，在第一个 action 中存储到了 session 中，到另外一个 action 中要取出来时告诉我：

#<ActionDispatch::Request::Session:0x7fe558031480 not yet loaded>

我现在想：要不直接调用第一个 action 时写到服务器端的一个文件中，第二个 action 中把这个文件中的值取出来，似乎也可行... 【更新：似乎用@@开头的变量就可以了】

@huacnlee 谢谢，可是我既没有 model 层也没有 view 层，是一个非常简单的 api mock server 工程，用来配合做测试的。

@u1440247613 那可能要看 status 存放在哪里了，如果存放在 session 中【不知道可不可行...】，那应该就不会影响到其他用户了，因为 session 默认是存放在客户端的。如果存放在服务器端的一个文件或内存中，那是会影响到其他用户的。不过当前只有 1 个用户～

@chenjau 现在实际情况确实因为某种原因拆开了，比如 details 表中的字段比较多，如果合并在一起，可能只有少量的中文书的数据需要这么多字段，其他大部分外文书的数据这些字段都空着...

@xiaoronglv @jasl @qinfanpeng @leiz_me 谢谢回复。 总结一下就是尽量要明确地指定希望捕获的异常类型，同时不要尝试去捕获程序逻辑上的问题，要让这些错误尽早暴露出来。

谢谢 LS 同学们的回答，明白啦 @elele @rei @hooopo 另外好像现在帖子有回复的通知有些问题，没有提醒有新的回复...

@lgn21st 好的 谢谢啦 周末我来先看看 Ruby 线程的基础概念

@xiaoronglv 可能会有什么 bug 呢，能具体说说或者举个例子么？我也是第一次用Thread.new的这种方式

感谢 LS 同学们的回复。

@xworm 就是 5 楼@lgn21st同学做的一个分享，不过主要是说WebSocket的，你可以去 RubyConfChina 的资源集合贴里去看看。

@zlx_star 我的 Thread 里主要是发送一堆 api 请求，并没有对异常做任何处理，失败了估计也就失败了。那如果对这些不处理，暂时不知道有没有什么问题。

@huacnlee 感谢提醒，我的原始需求是：直接在 controller 中返回 action 的结果，例如 render json 字符串，然后再接着发送 api 请求。那这应该算是异步的？ 我原先的代码逻辑大概是：

def action
  post_api
  post_api
  render json: "true" # 这样需要等待post api全部发送完成之后才会执行
end

现在修改成这样了：

def action
  Thread.new do
    post_api
    post_api
  end
  render json: "true" # 改成这样就直接返回了，post api可以在后台慢慢做
end

@azhao 开放给自己内部同学们用，暂时是两套接口都做了。 因为有的地方只会调用得到粒度细的接口，有的地方则希望调用粒度粗的接口。

@uudui 事物 => 事务？嗯，有道理，是要考虑事务性。

@jimrokliu 关于是否好理解，其实两种方案，看起来都挺容易理解的。

站在接口调用方的角度，自然是希望接口越少越简单越好，如果有一个接口，可以满足所有需求，当然是最好的啦。不需要管后端是更新、删除或者新增操作，涉及到几张表，调用方当然是希望这种实现上的业务逻辑越少接触越好。

站在接口实现方的角度，则是希望接口的功能能够清晰明确。可是拆分得过细则必然会导致接口调用次数增加，HTTP 请求还是挺耗时的。

其实就是希望找到一个平衡点。

@billy 那如果遇到需求方提出确实需要这种批量插入的 API 呢？ 我觉得批量插入 10 个，失败其中 1 个，这种情况似乎和接口设计得 RESTful / non-RESTful 并没有什么大的关系？...

@hging 好的，3Q～

@hging 那请问在 request 的 body 中该怎么样写，rails 才能把参数转变成这样呢？

book[][name]: aaa
book[][author]: bbb

这样么？

我在定义接口文档，需要告诉别人要怎么样调用。

想请教一下 LZ 为什么第一步里需要 disable 掉 cookie？是有安全性方面的考虑么？