这两个方法咋一看均可以更新资源,可是有本质区别的html
具体定义能够百度,我这里就不贴了,光说我本身的理解前端
首先解释幂等,幂等是数学的一个用语,对于单个输入或者无输入的运算方法,若是每次都是一样的结果,则称其是幂等的api
对于两个参数,若是传入值相等,结果也等于每一个传入值,则称其为幂等的,如min(a,b)浏览器
POST缓存
用于提交请求,能够更新或者建立资源,是非幂等的服务器
举个例子,在咱们的支付系统中,一个api的功能是建立收款金额二维码,它和金额相关,每一个用户能够有多个二维码,若是连续调用则会建立新的二维码,这个时候就用POST网络
PUT架构
用于向指定的URI传送更新资源,是幂等的app
仍是那个例子,用户的帐户二维码只和用户关联,并且是一一对应的关系,此时这个api就能够用PUT,由于每次调用它,都将刷新用户帐户二维码ui
好比一个接口用于用户生成,接收的数据是用户名、密码等相关信息,则用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
我的理解为:表现形式的状态传递
一、只有一个接口交换xml来实现整个服务
目前咱们的移动站点的服务就是相似的结构,咱们有两个URI接口/mapp/lead和/msdk/safepay
二、每个资源对应一个具体的URI,比1好维护,可是问题依然很明显,资源版本更新会引入时间戳维护,资源的获取和更新修改必须对应不一样的URI
目前PC主站和移动站点的静态内容(包括html文件)都是这种形式
三、在2的基础上使用了http verb,每一个URI能够有不一样的动做,充分利用了http协议,因此天然竟然http协议的完整优点,好比缓存和健壮性
HTML4.0只支持POST和GET,因此不管DELETE仍是PUT操做,都用POST去模拟了
在WEB开发者看来,就是若是有数据变更,就用POST,若是没有,就用GET
因此目前中国用户来看,PC端实现RESTful很困难,只有移动端支持Html5的浏览器,才能让前端作出尝试
四、如今彷佛更加没法实际应用,Hypemedia control,也就是RESTful的本意,合理的架构原理和以网络为基础的设计相结合,带来一个更加方便、功能强大的通讯架构
这就有点虚无缥缈了,不过是一个努力的方向,想一想看,之后要缴水费了,打开浏览器,输入我要缴水费,就自动定位+自动下单+自动付款+自动展现结果,完成整个缴水费的过程,这是多么方便的领悟!gwy要失业了有木有,那帮吃白饭作很简单的事情的,生产力发展第1个要淘汰的就是阻碍生产力发展的落后生产关系……