zoukankan      html  css  js  c++  java
  • HTTP之为什么存在post,get,put,delete等多种类型请求(RESTful风格介绍)

    一、HTTP中定义了以下几种请求方法:

    1、GET;2、POST;3、PUT;4、DELETE;
    5、HEAD;6、TRACE;7、OPTIONS;

    二、各个方法介绍:

    1、GET方法:对这个资源的查操作。

    2、DELETE方法:对这个资源的删操作。但要注意:客户端无法保证删除操作一定会被执行,因为HTTP规范允许服务器在不通知客

    户端的情况下撤销请求。

    3、HEAD方法:与GET方法的行为很类似,但服务器在响应中只返回实体的主体部分。这就允许客户端在未获取实际资源的情

    况下,对资源的首部进行检查,使用HEAD,我们可以更高效的完成以下工作:

    在不获取资源的情况下,了解资源的一些信息,比如资源类型;

    通过查看响应中的状态码,可以确定资源是否存在;

    通过查看首部,测试资源是否被修改;

    4、TRACE方法:会在目的服务器端发起一个“回环”诊断,我们都知道,客户端在发起一个请求时,这个请求可能要穿过防火墙、代理、网关、或者其它的一些应用程序。这中间的每个节点都可能会修改原始的HTTP请求,TRACE方法允许客户端在最终将请求发送服务器时,它变成了什么样子。由于有一个“回环”诊断,在请求最终到达服务器时,服务器会弹回一条TRACE响应,并在响应主体中携带它收到的原始请求报文的最终模样。这样客户端就可以查看HTTP请求报文在发送的途中,是否被修改过了。

    5、OPTIONS方法:用于获取当前URL所支持的方法。若请求成功,则它会在HTTP头中包含一个名为“Allow”的头,值是所支持的方法,如“GET, POST”。

    二、方发之间的区别:

    1、PUT和POST

    PUT和POS都有更改指定URI的语义.但PUT被定义为idempotent的方法,POST则不是.idempotent的方法:如果一个方法重复执行

    多次,产生的效果是一样的,那就是idempotent的。也就是说:

    PUT请求:如果两个请求相同,后一个请求会把第一个请求覆盖掉。(所以PUT用来改资源)

    Post请求:后一个请求不会把第一个请求覆盖掉。(所以Post用来增资源)

    2、get和post

    1、GET参数通过URL传递,POST放在Request body中。

    2、GET请求会被浏览器主动cache,而POST不会,除非手动设置。

    3、GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。

    4、Get 请求中有非 ASCII 字符,会在请求之前进行转码,POST不用,因为POST在Request body中,通过 MIME,也就可以传输非 ASCII 字符。

    5、 一般我们在浏览器输入一个网址访问网站都是GET请求

    6、HTTP的底层是TCP/IP。HTTP只是个行为准则,而TCP才是GET和POST怎么实现的基本。GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。但是请求的数据量太大对浏览器和服务器都是很大负担。所以业界有了不成文规定,(大多数)浏览器通常都会限制url长度在2K个字节,而(大多数)服务器最多处理64K大小的url。

    7、GET产生一个TCP数据包;POST产生两个TCP数据包。对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。

    8、在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。但并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。

    内容整理来源如下:

    http://www.cnblogs.com/logsharing/p/8448446.html

    http://www.cnblogs.com/shanyou/archive/2011/10/17/2215930.html

    http://www.jellythink.com/archives/806
    ————————————————
    版权声明:本文为CSDN博主「田园园野」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/qq_36183935/article/details/80570062

    ===================================================================================

    目录

    一、传统常用对数据操作API接口方式

    1.请求URI路径命名与请求方式type混乱

    2.混乱的URI命名与Type类型导致资源的来源复杂多样

    3.状态性(我们一般访问的网页都是有状态)

    4. 返回结果重定义

    二、RESTful风格例子

    1.URI请求命名规则与请求方式

    2.返回状态码 

    三、RESTful风格系统特点

    1.CS结构

    2.无状态

    3.可缓存

    4.分层系统

    5.统一接口

    6.按需代码(扩展性)可选

    一、传统常用对数据操作API接口方式
    1.请求URI路径命名与请求方式type混乱
    一千个读者就有一千个哈姆雷特,大多数程序员在URI命名时都采取见明知意的方式,使用get或者post解决所有数据的CRUD,如以下方式

    http://localhost:8080/mallWeb/getAllProducts    ---get查

    http://localhost:8080/mallWeb/getSomeProductsById?id=10086    ---get查

    http://localhost:8080/mallWeb/saveUserInfo    ---post增

    http://localhost:8080/mallWeb/updateUserInfoById?id=10086    ---post改

    http://localhost:8080/mallWeb/deleteUserInfoById?id=10086    ---post删

    每个人都有自己命名的一套规则与请求方式,导致http协议显得混乱,甚至完全忽略了其他请求方式如put、delete等,如果不是因为get请求uri长度限制(一般为2kb),或许很多人通篇get请求,再无其它

    2.混乱的URI命名与Type类型导致资源的来源复杂多样
    混乱的URI命名导致一个独立的URI地址,无法对应一个独一无二的资源。一个资源,对应了多样v来源;你有没有想过这样一个环境,一个独立的URI地址,对应一个独一无二的资源(RESTful风格);比如:我是一名理发师,需要为顾客理发;定义如下URI:

    /hairStyle/{customer_id},一个顾客就对应一套理发流程;如/hairStyle/mark,表示我现在需要为mark做一整套理发流程。现在再想想我们之前常用的命名方式

    wash/hairStyle/mark,为mark顾客洗头

    cut/hairStyle/mark,为mark顾客剪头

    dry/hairStyle/mark,为mark顾客吹头

    如果我们可以用/hairStyle/mark表示一整套流程,(已经定义了各种type)

    如果你要为顾客洗头,追加type=wash;

    如果你要为顾客剪头,追加type=cut;

    如果你要为顾客剪头,追加type=dry;

    这就是RESTful风格之一了,怎么样是不是很清爽呢!Http请求协议中有8中类型!!!想想你用了几种呢?

    3.状态性(我们一般访问的网页都是有状态)
    有状态:后面每一个状态都依赖于前面的状态,如果前面的无法访问,后面的也不会请求成功,如:

    有状态:

    员工登录OA系统----进入个人信息中心----进入薪资查询----输入密码----查询工资

    如果其中的某个环节操作不成功,都无法查询工资成功

    无状态(RESTful风格):

    如果输入一个url即可得到指定员工的工资,则这种情况是无状态的,因为获取工资不依赖于其他资源或状态

    http://oa.wasion.com/salary/mark,直接可以获取到mark的工资,这种就是无状态的

    4. 返回结果重定义
    我想很多人应该封装过如下实体吧,服务器返回错误信息都会封装在Http协议状态码中,我们依然还会错误信息封装在返回值中,返回的状态码一律都是200,返回了true或者false,前端拿到返回值后还要去解析到底是true还是false

    public class Json implements java.io.Serializable {

    private boolean success = false; //返回是否成功

    private String msg = "";//返回消息

    private Object obj = null;//返回数据


    //get与set...

    }
    二、RESTful风格例子
    1.URI请求命名规则与请求方式
    GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,Delete用来删除资源

    URI的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关,操作是通过 HTTP动词来体现,所以RESTful风格中 通过 URI 暴露资源时,会强调不要在 URI 中出现动词

    原始风格

    http://localhost:8080/mallWeb/getAllproducts   ---Get (获取所有商品信息)

    http://localhost:8080/mallWeb/getProductById?id=pro_id   ---Get (获取某个商品信息)

    http://localhost:8080/mallWeb/SaveOneProduct    ---Post (添加一个商品信息)

    http://localhost:8080/mallWeb/UpdateSomeproductsById?id=pro_id     ---Post(修改一个商品信息)

    http://localhost:8080/mallWeb/DeleteSomeproductsById?id=pro_id     ---Post(删除一个商品信息)

    RESTful风格 

    http://localhost:8080/mallWeb/rest/api/products   ---Get (获取所有商品信息)

    http://localhost:8080/mallWeb/rest/api/products/:pro_id   ---Get (获取某个商品信息)

    http://localhost:8080/mallWeb/rest/api/products    ---Post (添加一个商品信息)

    http://localhost:8080/mallWeb/rest/api/products/:pro_id    ---Put(修改一个商品信息)

    http://localhost:8080/mallWeb/rest/api/products/:pro_id     ---Delete (删除一个商品信息)

    URI名称 方法 描述
    /orgz/members

    GET

    获取成员列表

    /orgz/members/120

    GET

    获取单个成员

    /orgz/members

    POST

    创建成员

    /orgz/members/120

    PUT

    修改成员

    /orgz/members

    PUT

    批量修改

    /orgz/members/120

    PATCH

    修改成员的部分属性

    /orgz/members/120

    DELETE

    删除成员

     2.返回状态码 
     返回值加入返回状态码(code),虽然Http请求本身已经有了完备的状态码,再定义一套状态码直观上感受却是不对劲。但是实际开发中,确实发现自定义业务状态码的必要性,如一次成功的Http status 200的请求,可能由于用户未登录、登录过期而有不同的返回结果和处理方式,所以还是保留了状态码(code)

    public class Json implements java.io.Serializable {

    private boolean success = false; //返回是否成功

    private String msg = "";//返回消息

    private Object obj = null;//返回数据

    private String code = ""; //返回状态码

    //get与set...

    }
    状态码的定义也最好有一套规范,如按照用户相关、授权相关、各种业务,做简单的分类 

    // Code 业务自定义状态码定义示例

    // 授权相关
    1001: 无权限访问
    1002: access_token过期
    1003: unique_token无效
    ...

    // 用户相关
    2001: 未登录
    2002: 用户信息错误
    2003: 用户不存在

    // 业务1
    3001: 业务1XXX
    3002: 业务1XXX
    三、RESTful风格系统特点
    1.CS结构
    客户端-服务器结构

    2.无状态
    服务器端不能存储来自某个客户的某个请求中的信息,并在该客户的其他请求中使用

    3.可缓存
    服务器必须让客户知道请求是否可以被缓存

    4.分层系统
    服务器和客户之间的通信必须被这样标准化:允许服务器和客户之间的中间层(Ross:代理,网关等)可以代替服务器对客户的请求进行回应,而且这些对客户来说不需要特别支持

    5.统一接口
    客户和服务器之间通信的方法必须是统一化的(GET,POST,PUT,DELETE,etc)

    6.按需代码(扩展性)可选
    服务器可以提供一些代码或者脚本(Javascrpt,flash,etc)并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。(比如客户可以在客户端下载脚本生成密码访问服务器。)
    ————————————————
    版权声明:本文为CSDN博主「绣花针」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/mmake1994/article/details/88633636

  • 相关阅读:
    LeetCode 252. Meeting Rooms
    LeetCode 161. One Edit Distance
    LeetCode 156. Binary Tree Upside Down
    LeetCode 173. Binary Search Tree Iterator
    LeetCode 285. Inorder Successor in BST
    LeetCode 305. Number of Islands II
    LeetCode 272. Closest Binary Search Tree Value II
    LeetCode 270. Closest Binary Search Tree Value
    LeetCode 329. Longest Increasing Path in a Matrix
    LintCode Subtree
  • 原文地址:https://www.cnblogs.com/2019gdiceboy/p/12134120.html
Copyright © 2011-2022 走看看