第一个问题:个人观点,不一定符合restfull规范,resource定义可以更灵活一点,同样的resource,可以增加定语来适应不同的场景.而批量的场景,可以在post或put中兼容. 不建议API按页面来定义,有时候一个页面需要请求2-3个接口,有极小的性能损失,但是跟语义清晰,扩展性这些优点比起来,可以接受. 第二个问题:有restful规范是好的,好处是,这个规范不用培训.url的构建,实在不是问题.

不过我们做的时候没太遵循restful规范,为了简单,也没有用/api/v1/users/{id}/stories这样的方式,所以也没遇到什么障碍.对于url的方式,我们也是更倾向于使用?id=xxx&name=xxx这样的方式.这样的方式好处非常明显,使用key value的方式,可读性比较好(不需要查文档),扩展性也比较好,比如search这样的场景,筛选条件是不定的.

兴趣很重要，人生目标也很重要。做好职业规划。选择了就要坚持，做到最好。个人拙见。

楼上说的有道理，架构是抽象的。mvc没有对实现细节进行描述，比如业务逻辑应该在哪一层。一个典型的复杂web应用也不能用mvc概括，因为这样会导致一个控制器几千行代码，太常见了。

确认瓶颈所在了？数万人这个量级实在太低了

http://git.oschina.net/progit/ http://nvie.com/posts/a-successful-git-branching-model/

1 通读git, 2 在 github或者oschina 上弄个项目练。 3 过一遍git-flow ,记住那张经典的图， 4 重复2，记住看每个命令的返回信息，它会告诉你git-flow到底干了什么

基本就会了 再到项目实践，会遇到一些问题，到时候再往深了研究。

挺不错的，工作意向呢，比如想找什么方向，还有想从事什么技术的开发？如果有match的，我可以推荐。

这个问题设计成两步操作会更简单。 第一步，产生一个后台统计任务，将统计结果保存到表，或者其他中间存储。 第二步，查询统计结果，基于统计结果，点击导出。

如果一定要等待然后应答，就用楼上的回答。

1:1是个坑

同意楼上的,最好的方案通常不是讨论出来的,一般自己认定的东西就很难改变了.自己用用就知道了,现在的软件迭代速度都很快.用完了,再回来看看.没什么问题就继续用,不好就重构.