理解POST和PUT的区别,顺便提下RESTful

这两个方法咋一看都可以更新资源,但是有本质区别的

具体定义可以百度,我这里就不贴了,光说我自己的理解

首先解释幂等,幂等是数学的一个用语,对于单个输入或者无输入的运算方法,如果每次都是同样的结果,则称其是幂等的

对于两个参数,如果传入值相等,结果也等于每个传入值,则称其为幂等的,如min(a,b)

POST

用于提交请求,可以更新或者创建资源,是非幂等的

举个例子,在我们的支付系统中,一个api的功能是创建收款金额二维码,它和金额相关,每个用户可以有多个二维码,如果连续调用则会创建新的二维码,这个时候就用POST

PUT

用于向指定的URI传送更新资源,是幂等的

还是那个例子,用户的账户二维码只和用户关联,而且是一一对应的关系,此时这个api就可以用PUT,因为每次调用它,都将刷新用户账户二维码

比如一个接口用于用户生成,接收的数据是用户名、密码等相关信息,则用POST

RESTful建议所有的URI都是对应资源,所以创建用户不应该理解为一个行为,在此将此接口命名为:

/user/creation

每次调用它都会新建一个用户(假定用户名可以重复)

而PUT方法更加关心一个具体资源对应的URI,比如更新当前用户信息,这里可以用PUT

/user/me/update

这里用me来指代当前用户,如果是针对更多用户适用的接口,可以考虑

/user/{uid}/update

注意多次调用同一接口,只要提交的数据一致,用户信息每次结果就会一致,即产生同样的结果:服务器端某个具体的资源得到了更新

当需要以更新的形式来修改某一具体资源的时候,如何判断用PUT还是POST呢?

很简单,如果该更新对应的URI多次调用的结果一致,则PUT

比如更新某个blog文章,因为该文章具有单一的具体URI,所以每次更新提交相同的内容,结果都一致

/blog/{document_id}/update

在每次更新提交相同的内容,最终的结果不一致的时候,用POST

举个很常见的例子,一个接口的功能是将当前余额减一个值,每次提交指定该值为100,接口如下

/amount/deduction

调用一次,你的余额-100,调用两次,余额-200

这个时候就用POST

RESTful的4种层次

Representational status transfer

个人理解为:表现形式的状态传递

1、只有一个接口交换xml来实现整个服务

目前我们的移动站点的服务就是类似的结构,我们有两个URI接口/mapp/lead和/msdk/safepay

2、每一个资源对应一个具体的URI,比1好维护,但是问题依然很明显,资源版本更新会引入时间戳维护,资源的获取和更新修改必须对应不同的URI

目前PC主站和移动站点的静态内容(包括html文件)都是这种形式

3、在2的基础上使用了http verb,每个URI可以有不同的动作,充分利用了http协议,所以自然居然http协议的完整优势,比如缓存和健壮性

HTML4.0只支持POST和GET,所以无论DELETE还是PUT操作,都用POST去模拟了

在WEB开发者看来,就是如果有数据变动,就用POST,如果没有,就用GET

所以目前中国用户来看,PC端实现RESTful很困难,只有移动端支持Html5的浏览器,才能让前端做出尝试

4、现在似乎更加无法实际应用,Hypemedia control,也就是RESTful的本意,合理的架构原理和以网络为基础的设计相结合,带来一个更加方便、功能强大的通信架构

这就有点虚无缥缈了,不过是一个努力的方向,想想看,以后要缴水费了,打开浏览器,输入我要缴水费,就自动定位+自动下单+自动付款+自动展示结果,完成整个缴水费的过程,这是多么方便的领悟!gwy要失业了有木有,那帮吃白饭做很简单的事情的,生产力发展第1个要淘汰的就是阻碍生产力发展的落后生产关系……


转载于:https://my.oschina.net/u/1263964/blog/268932

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值