REST 设计中要兼顾效率和功能是很困难的，不同公司对REST 的理解不同，最终也会导致不同的设计
举一个例子，
请求所有课程中满足一定过滤条件的数目
方案1：
GET /api/v1/courses?fileds=count(*) & filter = isAvaliable eq false
方案2： Cooked API
GET /api/v1/courses/available/count
GET /api/v1/courses/unavailable/count
在海量数据下供Mobile访问，表面上看方案2的效率可能会很高，但仅仅是一个个REST 服务， 并不是 REST 框架，小心设计方案1都可以达到同样的效率。
如果要做一个好的框架，应该尽量用方案1的方式，这样代码的复用程度会高一些，性能方面的可能会差一些，因为多了一些解析工作。
当然，做一个功能强大而且扩展性好REST框架，是需要很大人力物力的。可以使用现有ODATA之类的成熟的产品，也支持各种语言接口。缺点就是定制化比较困难。
怎么选择，取决公司的实力和成本。
如果有 candidates 说自己精通 REST 但实际上只是用Spring MVC 开发 cooked API interfaces， 我就只能呵呵了。
阅读(740) | 评论(0) | 转发(0) |
