PHP[转]拙议REST及其在PHP中的现状

正文并不想开始介绍REST,只是想举例表达在HTTP中应用REST必要留意的标题:

先来探望人们对REST的迷离

REST长啥样?

最相似的REST例子,类似上面包车型地铁规范:

POST   /articles     创建
DELETE /articles/123 删除
PUT    /articles/1二三 更新或成立
GET    /articles/123 查看

附带说说多少个知识点:

GET操作是高枕而卧的。所谓安全是指甭管实行多少次操作,财富的图景都不会变动。比如笔者用GET浏览小说,不管浏览多少次,这篇小说还在那,未有转换。当
然,你大概说每浏览贰次作品,小说的浏览数就加壹,那不也改成了财富的情事么?这并不争辨,因为那些更改不是GET操作引起的,而是用户自个儿设定的服务端
逻辑产生的。

PUT,DELETE操作是幂等的。所谓幂等是指甭管实行多少次操作,结果都壹律。比如本人用PUT修改壹篇小说,然后在做同样的操作,每趟操作后的结果并未区别,DELETE也是同样。顺便说一句,因为GET操作是平安的,所以它自然也是幂等的。

POST操作既不是平安的,也不是幂等的,比如大规模的POST重复加载难点:当大家往往爆发同样的POST请求后,其结果是创建出了若干的能源。

平安和幂等的含义在于:当操作未有完结预期的目标时,我们能够不停的重试,而不会对财富发生副效能。从这一个含义上说,POST操作往往是重伤的,但好多时候大家依旧不得不选用它。

还有有些急需专注的就是,成立操作能够接纳POST,也得以使用PUT,差异在于POST是职能在一个汇集能源之上的(/articles),而PUT操
作是功力在三个实际财富之上的(/articles/123),再通俗点说,假使UCR-VL能够在客户端明确,那么就利用PUT,借使是在服务端分明,那么就
使用POST,比如说繁多财富使用数据库自增主键作为标记新闻,而创办的能源的标记信息到底是什么样只可以由服务端提供,这年就非得采用POST。

浏览器不帮忙PUT/DELETE方法怎么办?

多数浏览器只补助GET/POST方法,那使得大家不可能全面的兑现REST。对于这么的状态,大约有三种缓解措施,壹种是在表单里投入一个
_method之类名字的隐藏字段,用于表示确实的法子,另1种是行使X-HTTP-METHOD-OVEHummerH二酷威IDE头信息来重载POST。

HTTP方法够用么?

从地点的例子,大家能够见到,通过利用已有的HTTP方法:POST,DELETE,PUT,GET就足以做到能源的增加和删除改查,但在骨子里情形中,大家要求做的操作往往并不仅仅局限在大约的增删改查操作中,比如说大家要把壹篇作品“置顶”,不过HTTP方法里不曾1个和“置顶”操作绝对应的措施,那时候该如何是好吧?REST对类似难题的消除方案是:成立1个新的能源!在上头的例子里,大家得以如此:

PUT /top_articles/123

因此创制出二个新的财富(top_articles),大家就能够利用简易的HTTP方法通吃一切操作了。

何以规划能源的URAV4L?

最广大的能源命有名的模特式是/controllers/id,然则那不是必须的,REST并未强制规定U劲客L必须符合哪个种类样式,你大能够依据自身的怀念去随便的布置,实际编程时大致有二种艺术:

一种是依据路线变量的命名,如:/china/beijing/laowang

根据路线变量的命名格局一般用来讲述具备层次化的构造的能源。

另1种是依据查询变量的命名,如:/person?name=laowang

听新闻说查询变量的命名方式相似用来描述某种算法的估算结果。

毕竟是行使基于路线的命名格局,还是基于查询的命超情势,取决于你看标题标角度和个体的喜好。

REST反对利用Session么?

REST拒绝Session!这是因为REST强调无状态性。那里的情景指的的采用状态,也足以叫做会话状态。1旦在服务端保持了这样的动静,那么架构的可扩大性将大减价扣。在REST看来,任何像样的气象本人都应有是二个单身的能源。

但也有人感觉,以后可以很有益的把session存款和储蓄在memcached之类的分布式缓存中,所以不是主题素材。

Cookie对REST有害么?

1分为二的看,如若Cookie里保存的是利用状态以来,就不曾难题。因为使用状态自然就属于客户端。但若是采取Cookie保存类似PHPSESSIONID之类的事物就难堪了,因为这么的多寡并不属于客户端状态,它只不过是采纳Session的假说而已。

再来看看REST在PHP中的现状

PHP里的REST实现案例不多,有点影响都正是CakePHP和Zend,下边分别探访她们的兑现:

CakePHP:

设定路由:

Router::parseExtensions(‘xml’);
Router::mapResources(‘articles’);

编辑调控器:

class ArticlesController extends AppController {

var $components = array(‘RequestHandler’);

function view($id = null) {
$article = $this->Article->findById($id);
$this->set(compact(‘article’));
}

// …
}

视图:

<articles>
<?php echo $xml->serialize($article); ?>
</articles>

大概就好像此了,相应的,还是能够完结别的的意义,于是,如下REST操作便成为大概:

POST   /articles
DELETE /articles/123.xml
PUT    /articles/123.xml
GET    /articles/123.xml

全体看,CakePHP的REST达成基本上是按Rails风格来得以达成的,大要还过得去。

参考链接:

http://book.cakephp.org/view/476/rest
http://c7y.phparch.com/c/entry/1/art,cakephp-rest

ZendFramework:

ZendFramework通过Zend_Rest组件来贯彻Rest功用:

服务端:

require_once ‘Zend/Rest/Server.php’;

function sayHello($who, $when)
{
return “Hello $who, Good $when”;
}

$server = new Zend_Rest_Server();
$server->addFunction(‘sayHello’);
$server->handle();

客户端:

require_once ‘Zend/Rest/Client.php’;

$client = new Zend_Rest_Client(‘http://path/to/server/script‘);
$client->sayHello(‘Davey’, ‘Day’);

echo $client->get();

此时,大家看一下Web服务器的日记,会发觉生成了一条之类的笔录:

GET /path/to/servier/script?method=sayHello&arg0=Davey&arg1=Day&rest=1
HTTP/1.1

大家发现,实操方法是由U本田UR-VL中的method=sayHello钦定的,而HTTP固有主意(GET/POST等)则改为了安置,那是典型的RPC
风格,假使大家对待Zend_Rest和Zend_Xml酷威pc文书档案的话,会分明发现它们根本正是贰个事物,所以说,Zend_Rest是一个REST伪
实现。

参照链接:

http://framework.zend.com/manual/en/zend.rest.html
http://framework.zend.com/manual/en/zend.xmlrpc.html

=============================

其余,还有几篇不错的篇章:

http://www.berenddeboer.net/rest/
http://www.ibm.com/developerworks/webservices/library/ws-restful/
http://www.infoq.com/cn/articles/rest-architecure
http://www.infoq.com/cn/articles/rest-introduction
http://www.infoq.com/cn/articles/rest-anti-patterns
http://www.infoq.com/cn/articles/webber-rest-workflow
http://www.infoq.com/cn/articles/tilkov-rest-doubts
http://www.infoq.com/cn/articles/designing-restful-http-apps-roth
http://www.infoq.com/cn/articles/roa-rest-of-rest

相关文章