第一个问题：个人观点，不一定符合 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 概括，因为这样会导致一个控制器几千行代码，太常见了。

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

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

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

1:1 是个坑

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

如果你的数据库主键用 A-1，也没什么话说。如果不是的话，最好做好 A-1 和电影票 id 的唯一约束。

不然后台人员增删座位会让你疯掉。

介于上面的原因，还是 id 吧。

这个好解决，找你领导就行。很多人，怕麻烦，吃哑巴亏。

但是有一点，一般公司都不愿意给你算税后工资。

你自己算下就知道有多麻烦了。

五险一金，缴税，补贴什么的，需要根据你的税后工资倒推出来。不同的公司的绩效，福利还不一样，还有些福利还要谈判，公司每个人要这么一算，还真是不简单的事。

所以，我的建议是，先把你的认为可接受的税后工资范围算出来，然后倒推下。算下税前工资范围，根据现场谈判的结果，提高或者降低税前工资。

好像是程序员都会面临的问题。个人想法，希望对你有所参考。

我的工作经历告诉我，

平台很重要，工资不重要。

圈子很重要，能让你找到合适的平台。

找到好的平台后，好好成长，耐得住寂寞，经得住诱惑。这段时间对于大多数人来说，基本也是月光，钱够买书付网费就行了。

等你羽翼丰满的时候，再找一个新的平台，发挥你的价值，让别人认可你。这个时候相信工资会让你满意。

当然不是就这么结束了。后面的，你懂的，好多大师级的程序员在前面等着你。

最后，我的觉得，作为一个程序员，真的需要沉下心来，好多要学的，要研究的。

多逛逛论坛，牛人聚集的地方，总有一些你想要的东西。

赞，慢慢拜读

@wangping 不是的，我的意思是在设计的时候，规避这种情况。规避这种情况的方法有这么几种，

1.数据查询类的比较简单。比如一个商品接口，原先没有提供多图，后来需要提供多图的，简单的增加一个多图集合字段就可以。又比如商品需要增加优惠券信息，再增加优惠券的扩展字段就可以。

这样的增量接口，对于老的自动化测试来说，不会失效，仍然可以跑。这种都是比较简单的。

2 操作类的接口，尽可能的原子化，这样修改该一个功能的时候影响比较小。但是一般人都不太会犯这样的错误

3 比较难搞的是数据结构设计不合理。其实用楼主的方案比较可取，那就是新增一个接口。只能说尽可能避免。

V2 那种涉及大面积重构的. 建议是先保证原来的接口运转正常。然后监控客户端升级状态。

个人经验，不知是否有帮助. 对版本接口维护，个人认为是灾难性的。不同版本的业务逻辑，需要操作最新版本的数据结构。同时还要维护各版本的文档，各版本的自动化测试或者人工测试 ok.

所以个人认为比较好的做法是。

在开始设计的时候， 查询类的接口，应尽可能使用被动式提供数据的无状态接口，格式应竟可能使用对象 (不使用二维的集合).这样的接口对于扩展字段非常的方便，也很容易做到向下兼容. 操作类的接口，尽可能地将资源分离，比如修改用户信息，跟修改用户头像信息或者修改用户职位信息，这样的接口，尽可能使用独立的资源。

对于实在没有办法需要全面升级接口的. 如果可能，保持原有的业务，原有的接口运转正常. 然后构建一套全新的隔离的接口. 最后做下版本使用监控。当观察到所有用户都使用新版本的客户端的时候，并保持一段时间的时候。放弃对老版本的维护，继而下掉老版本的资源。当然，万不得已的时候，还可以用强制更新。

单身汉的话，还不错

觉得 DRY 的话，可以自己抽象出行为，统一封装。显式的 if else 肯定是不怎么优雅，可读性也比较差。

首页有错别字，提个醒 :)

好书，坐等补货

勤奋的姑娘，有志者事竟成

nice job，浅显易懂，分享是好习惯。

赞一个

#31 楼 @QueXuQ 深表同情，再奔个好前程吧~

Rails 实践很棒，感谢推荐~~~

如果把编程看做是一种爱好，那么你就每天在做自己想做的事，又能拿钱。 真在好的公司是只看产出不看考勤的，他会信任他的员工在工作时间都是高效的。 并且会为员工创造舒适的环境和提供各种福利，让他们工作的很开心，从而不用担心离职率的问题。

加不加班，其实个人认为，主要原因在于这个公司是否有一个靠谱的产品和一个靠谱的技术团队。 这样团队就不会为了那些多余的工作买单。 加班严重的公司，其实你过去，看看产品原型和翻翻代码也就明白了什么原因了。

当然还会有其他原因，但是大多数都是看上去像上面那样的。

nice job!

期待更多的作品