互联网创业的准备--框架：从MVC到开放API-web api mvc

MVC是传统web服务的常用框架，直到出现新的需求：私有API、开放API，还有业务庞大后进行soa拆分，这就需要新的框架了。

关于MVC，有一个经典讲解：http://www.symfony-project.org/jobeet/1_2/Doctrine/zh_CN/04

对这张图进行修改和细化：

1、controller只支持http(s)，不支持cli命令行

http参数的获取和cli完全不一样，web服务用不上cli，所以只支持http(s)。

2、一个uri应只支持一种http method

从安全和http规范两个方面来说，一个uri应只支持一种http method，不能让一个请求即支持get又支持put、post，所以在controller中的每个action都要指定一种http method，如果请求不符合method，返回错误。

安全：假如修改个人签名的页面提交地址为http://example.com/user/status，参数为content=xxxx，用户请求时验证本人cookie即可。这个页面接口应该只支持post，如果同时支持get，会出现什么问题？user 1发表了一张图片<img src="http://example.com/user/status?content=某商城促销，地址xxxxx" alt="" />，很明显这张图片是无法显示的。当user 1的所有好友user 2、user 3看到这张图片时，浏览器尝试载入图片，就会自动把user 2、user 3的签名改成广告。这就是典型的sns攻击的原理。

http规范：http://book.douban.com/subject/3094230/

3、MVC各层职责与禁止

index.php：职责——作为入口——根据路由规则，把uri请求映射到某个controller；作为出口——接收controller层返回的数据，然后输出

controller：职责——取http数据$_GET、$_POST、put、delete，然后作为参数传递给model层，把model层返回的数据传递给view层。一个uri只支持一种http method。禁止——使用$_REQUEST。

model：职责——处理业务，向下调用dao（数据访问对象），由于不知道下层用的是什么sql，所以无法写sql。禁止——写SQL，取http数据（$_GET、$_POST）。

dao：职责——根据原子业务，封装各种存储（mysql、pgsql、mongodb、hbase、memcache、redis、file）。确保当从mysql迁移到pgsql时，对外接口输入和输出不变。禁止——对外暴露用的是什么sql。

view：职责——只对数据进行显示格式处理。禁止——业务逻辑。

4、输出

页面返回html，订阅是atom。

5、异常

经过了PP面向过程的初级阶段，进入中等阶段class + return false的OOP，再进入高级阶段class + exception的彻底OOP，就会发现OOP的简洁易于维护。

Exception从底层说起比较清晰。

dao：catch 数据库异常（php是PDOException），throw 自定义错误码DaoException（打详细log，这种数据库错误应由log平台发出警报给工程师）。

model：catch DaoException，throw 自定义错误码ModelException。

controller：catch ModelException、catch所有Exception，return http状态码、content-type、数据、模板名称。如果是http状态码是302，还需要return uri。

index.php：index.php作为出口，接收到controller传来的结果，header输出http状态码，根据http status code决定是跳转还是输出，根据content-type决定是输出html、json还是atom。

todo参考：《错误码与状态码》

细化之后如下图：

todo细化：view层之多模板templates、view层之多layout与模块化、bigpipe

MVC框架细化到这个程度，能很好的支持传统web服务，直到出现了新的挑战：

1、移动互联网的需求，官方app需要api（开放或私有）：iPhone、Android智能手机逐渐普及，在手机上使用互联网服务更方便，各公司推出官方手机app，需要api。

2、开放帐号和数据的需求，第三方app需要api（开放）：随着sns的兴起，各大sns社区发现开放数据给开发者app，能够形成生态圈，能够盈利，OAuth这种授权方案流行了起来。开放的数据如果属于用户，那需要先开放帐号，用户登录授权第三方app获得头像、好友列表。如果是地图这种自有数据，则无需开放帐号。

3、开放帐号的需求：为什么到各个网站都要重新注册呢？于是出现了OpenID，但是使用不够方便，小白不容易理解，而且OpenID只做认证，各公司如果支持OpenID没有什么额外的价值。后来各社区开放数据时，采用了OAuth，OAuth用于授权也包含了类似OpenID的认证功能。所以现在流行用OAuth登录，而不是OpenID。比如在别的网站上或者app里“用Google帐号登录”、“用微博帐号登录”、“用QQ帐号登录”并且授权导入头像。

4、业务庞大后，按照soa进行拆分，也会面临跨产品线（服务）如何内部调用的问题。参考淘宝的数据拆分演进。

框架进化如下：