GET_PUT_POST的含义(Http).pdf

GET PUT POST 的含义（Http） POST /articles 创建 DELETE /articles/123 删除 PUT /articles/123 更新或创建 GET /articles/123 查看 顺便说说几个知识点： GET 操作是安全的。所谓安全是指不管进行多少次操作，资源的状态都不会改变。比如我用GET 浏览文章，不管浏览多少次，那篇文章还在那，没有变化。当然，你可能说每浏览一次文章，文 章的浏览数就加一，这不也改变了资源的状态么？这并不矛盾，因为这个改变不是GET 操作引 起的，而是用户自己设定的服务端逻辑造成的。 PUT，DELETE 操作是幂等的。所谓幂等是指不管进行多少次操作，结果都一样。比如我用PUT 修改一篇文章，然后在做同样的操作，每次操作后的结果并没有不同，DELETE 也是一样。顺便 说一句，因为GET 操作是安全的，所以它自然也是幂等的。 POST 操作既不是安全的，也不是幂等的，比如常见的POST 重复加载问题：当我们多次发出同 样的POST 请求后，其结果是创建出了若干的资源。 安全和幂等的意义在于：当操作没有达到预期的目标时，我们可以不停的重试，而不会对资源产 生副作用。从这个意义上说，POST 操作往往是有害的，但很多时候我们还是不得不使用它。 还有一点需要注意的就是，创建操作可以使用POST，也可以使用PUT，区别在于POST 是作用 在一个集合资源之上的（/articles ），而PUT 操作是作用在一个具体资源之上的（/articles/123 ）， 再通俗点说，如果URL 可以在客户端确定，那么就使用PUT，如果是在服务端确定，那么就使 用POST，比如说很多资源使用数据库自增主键作为标识信息，而创建的资源的标识信息到底是 什么只能由服务端提供，这个时候就必须使用POST。 关于GET POST 的混淆 先说相同点，只有了解了相同点之后才能理解为什么会发生混淆。 两者都能向服务器发送数据，提交的“内容”[注 1]的格式相同，都是 var_1=value_1var_2=value_2 get 和 post 区别如字面，一个是get （获取），一个是post （发送）。 get 用来告诉服务器需要获取哪些内容（uri+query），向静态页面（uri）请求则直接返回文件 内容给浏览器，向一个动态页面请求时可以提供查询参数（query ）以获得相应内容。 post 用来向服务器提交内容，主要是为了提交，而不是为了请求内容，就是说post 的初衷并不 要求服务器返回内容[注2]，只是提交内容让服务器处理（主要是存储或者处理之后再存储）。 get 和post 出现混淆是因为对提交的数据处理方法的滥用造成的，数据是无辜的。 混淆之一： 将get 提交的用来查询的字段当作是存储数据存入了服务器端文件或者数据库。然后就误以为 get 是用来提交用于存储的数据的。 混淆之二： 编写脚本在服务器端通过处理post 提交的数据并返回内容。只要有数据，就能用来进行判断， 脚本怎写是程序员的事，而不在乎数据来源的形式（post、get，或者是自己预设值的常量）。 这点功能上确实没问题，只是背离的其初始目的而已。 由于都是要传送数据，且数据格式相同（即使数据格式不同，只要能提取出相应数据）。使用的 时候难免出现张冠李戴，将get 数据用来存储、将post 数据用来检索返回数据。但是二者还是 有区别的（主要是根据其用途而“人为”[注3]造成的），get 的长度限制在2048 字节（由浏览器 和服务器限制的，这是目前IE 的数据，曾经是1024 字节），很大程度上限制了get 用来传递“存 储数据”的数据的能力，所以还是老老实实用来做检索吧；post 则无此限制（只是HTTP 协议规 范没有进行大小限制，但受限于服务器的处理能力），因此对于大的数据（一般来说需要存储的 数据可能会比较大，比2048 字节大）的传递有天然的优势，谁让它是 nature born post 呢。 get 提交的数据是放在url 里，目的是灵活的向服务其提交检索请求，可以在地址栏随时修改数 据以变更需要获取的内容，比如直接修改分页的编号就跳到另外一个分页了（当然也可能是 404 ）。post 提交的数据放在http 请求的正文里，目的在于提交数据并用于服务器端的存储， 而不允许用户过多的更改相应数据（主要是相对于在url 修改要麻烦很多，url 的修改只要点击 地址栏输入字符就可以了），除非是专门跑来编辑数据的。 花边：post 和get 的安全性在传输的层面上区别不大，但是采用url