put 和 post 的技术实现上应该是没有很大区别的。但在于协议上语义是很大区别。
那么区别是什么？
首先，HTTP协议使用的是URI，是一种表示资源标志，那么对应的HTTP Verb就是各种对资源的操作，GET，PUT，DELETE等，明确这些，再往下看。
PUT：client对一个URI发送一个Entity，服务器在这个URI下如果已经又了一个Entity，那么此刻服务器应该替换成client重新提交的，也由此保证了PUT的幂等性。如果服务器之前没有Entity ，那么服务器就应该将client提交的放在这个URI上。总结一个字：PUT。
对的，PUT的方法就是其字面表意，将client的资源放在请求URI上。对于服务器到底是创建还是更新，由服务器返回的HTTP Code来区别。
注：通过上面可以知道，如果用PUT来达到更改资源，需要client提交资源全部信息，如果只有部分信息，不应该使用PUT（因为服务器使用client提交的对象整体替换服务器的资源）。
POST：这个Verb是比较特殊。不同于一般的增删改，使用场景比较多。根据RFC文档上描述，有以下几个场景：（https://tools.ietf.org/html/rfc2616#section-9.5）
- Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation.
因为服务器在实现POST是不可预知，所以将其定义为不安全、不幂等的Verb。基本上不能方便的归纳为“增删改”之类的行为，都可以使用POST方法。（可以用于“创建不由client决定URI的资源”，但本质上跟第三个有点儿类似，所以我在使用时，基本按照第三个去理解）。另外使用POST去实现“部分更新资源”可以不错的。
如果只有语义上的区别，那么不遵守有什么问题呢？
如果只是个人开发或者公司内部这么规定，那也没有很大问题。但是规范上来说，不好。
规范带来的好处是很多的，就像是开发人员的语言一样，当大家遵守同样的规范，沟通才更容易，不至于导致出现问题。公司内部还行，但是如果牵涉到外部工具或者其他公司开发合作，那还是会有问题的。举个比较严重的例子。
chrome浏览器为了加快页面加载，会在页面预加载某些GET链接(跳转链接，非资源链接)，这样用户点那个链接时，加载速度就很快。有一个图片还是什么网站，使用GET请求，参数里面有个OPT用来表示动作。用户打开页面时，嵌入了OPT=“DEL”的链接在图片附近的表单中，然后就被Chrome删除了。
再举个其他可能接触的例子。公司可能使用工具解析client请求，来分析请求的分布等信息。如果client的User-Agent字段没有遵守协议标准，那么工具将无法正确统计，这样的例子很多。
标准的存在意义就是为了统一概念，这样即使从未见面的人，各个国家不同语种的人，甚至火星人也能轻松交流。最好的例子就是数学了。（HTTP很复杂，这里只是简单说下。留简去繁）
