Http定义了与 服务器的交互方法，其中除了一般我们用的最多的GET,POST 其实还有PUT和DELETE
根据RFC2616标准（现行的HTTP/1.1）其实还有OPTIONS,GET,HEAD,POST,PUT,DELETE,TRACE,CONNECT
简单地介绍一下吧。
http 的post 和 get 方法确实很多，通俗解释就是-------
新建一条记录的话就用post，
更新一条记录的话就用put.
<POST>
POST 方法被用于请求源服务器接受请求中的实体作为请求资源的一个新的从属物
POST方法的实际功能是由服务器决定的，并且经常依赖于请求URI（Request-URI）。POST提交的实体是请求URI的从属物，就好像一个文件从属于一个目录，一篇新闻文章从属于一个新闻组，或者一条记录从属于一个数据库。POST方法执行的动作可能不会对请求URI所指的资源起作用。在这种情况下，200（成功）或者204（没有内容）将是适合的响应状态，这依赖于响应是否包含一个描述结果的实体。如果资源被源服务器创建，响应应该是201（Created）并且包含一个实体，此实体描述了请求的状态。并且引用了这个新资源和一个Location头域。POST方法的响应是不可缓存的。除非响应里有合适的Cache-Control或者Expires头域。然而，303（见其他）响应能被用户代理利用去获得可缓存的响应。
<PUT>
PUT方法请求服务器去把请求里的实体存储在请求URI（Request-URI）标识下。
如果请求URI（Request-URI）指定的的资源已经在源服务器上存在，那么此请求里的实体应该被当作是源服务器关于此URI所指定资源实体的最新修改版本。如果请求URI（Request-URI）指定的资源不存在，并且此URI被用户代理定义为一个新资源，那么源服务器就应该根据请求里的实体创建一个此URI所标识下的资源。如果一个新的资源被创建了，源服务器必须能向用户代理（user agent） 发送201（已创建）响应。如果已存在的资源被改变了，那么源服务器应该发送200（Ok）或者204（无内容）响应。如果资源不能根据请求URI创建或者改变，一个合适的错误响应应该给出以反应问题的性质。实体的接收者不能忽略任何它不理解和不能实现的Content-*（如：Content-Range）头域，并且必须返回501（没有被实现）响应。如果请求穿过一个缓存（cache），并且此请求URI（Request-URI）指示了一个或多个当前缓存的实体，那么这些实体应该被看作是旧的。PUT方法的响应是不可缓存的。
POST方法和PUT方法请求最根本的区别是请求URI（Request-URI）的含义不同。POST请求里的URI 指示一个能处理请求实体的资源（译注：此资源可能是一段程序，如jsp 里的servlet） 。此资源可能是一个数据接收过程，一个网关（gateway，注：网关和代理的区别是：网关可以进行协议转换，而代理不能，只是起代理的作用，比如缓存服务器其实就是一个代理），或者一个单独接收注释的实体。对比而言，PUT方法请求里的URI标识请求里封装的实体一一用户代理知道URI 意指什么，并且服务器不能把此请求应用于其它资源（resource）。如果服务器期望请求被应用于一个不同的URI，那么它必须发送301（永久移动）响应；用户代理可以自己决定是否重定向请求。一个单独的资源可能会被许多不同的URI指定。如：一篇文章可能会有一个URI指定当前版本，而这个URI区别于这篇文章其它特殊版本的URI。这种情况下，对一个通用URI的PUT请求可能会导致其资源的其它URI请求被源服务器重定义。HTTP/1.1没有定义PUT方法对源服务器的状态影响。
等幂方法（Idempotent Mehtods）
方法可以有等幂的性质因为（除了出错或终止问题）N>0个相同请求的副作用同单个请求的副作用的效果是一样（译注：等幂就是值不变性，相同的请求得到相同的响应结果，不会出现相同的请求出现不同的响应结果）。方法GET，HEAD，PUT，DELETE都有这种性质。同样，方法OPTIONS和TRACE不应该有副作用，因此具有内在的等幂性。然而，有可能有多个请求的请求序列是不等幂的，即使在那样的序列中所有方法都是等幂的。（如果整个序列整体的执行的结果总是相同的，并且此结果不会因为序列的整体，部分的再次执行而改变，那么此序列是等幂的。）例如，一个序列是非等幂的如果它的结果依赖于一个值，此值在以后相同的序列里会改变。根据定义，一个序列如果没有副作用，那么此序列是等幂的（假设在资源集上没有并行的操作）。
相同的请求怎样处理由我们服务器决定，比如：一个创建一篇博文的uri,被请求两次时，假如我们的服务器认为他们是不一样的，那么这时就只能用post，而不能用put.
（注：引用自《超文本传输协议-HTTP/1.1（修订版）
另外一点：
1、PUT: 把消息本体中的消息发送到一个URL,跟POST类似，但不常用。
简单地说：通常用于向服务器发送请求，如果URI不存在，则要求服务器根据请求创建资源，如果存在，服务器就接受请求内容，并修改URI资源的原始版本。
-----PUT请求那些封装在Request-URI的实体。如果Request-URI引用一个已存在的资源，则该封装实体应该作为原始服务器上的修改版本。如果Request-URI不是指向一个已存在的资源，并且该URI可被请求的用户代码定义为新资源，则原始服务器可用此URI创建新的资源。如果新的资源被创建，这个原始服务器就必须通过201（Created）响应通知用户代理。如果已有资源被修改，则发送200或者204响应，表示成功完成了该请求。如果Request-URI既没有创建也没有修改资源，则应给予适当的错误响应来反映问题本质。实体的接受者不能忽略任何不理解或没有实现的Content-*（如Content-Range）头部，并且必须返回501响应。
如果请求经过缓存，并且Request-URI标识出一个或多个当前缓存的实体，则那些实体视为过期了。该方法的响应不会被缓存。
2、POST和PUT的请求根本区别
POST请求的URI表示处理该封闭实体的资源，该资源可能是个数据接收过程、某种协议的网关、或者接收注解的独立实体。然而，PUT请求中的URI表示请求中封闭的实体-用户代理知道URI的目标，并且服务器无法将请求应用到其他资源。如果服务器希望该请求应用到另一个URI，就必须发送一个301响应；用户代理可通过自己的判断来决定是否转发该请求。
