趣谈网络协议
刘超
网易研究院云计算技术部首席架构师
立即订阅
39587 人已学习
课程目录
已完结 51 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想成为技术牛人?先搞定网络协议!
免费
第一模块 通信协议综述 (4讲)
第1讲 | 为什么要学习网络协议?
第2讲 | 网络分层的真实含义是什么?
第3讲 | ifconfig:最熟悉又陌生的命令行
第4讲 | DHCP与PXE:IP是怎么来的,又是怎么没的?
第二模块 底层网络知识详解:从二层到三层 (5讲)
第5讲 | 从物理层到MAC层:如何在宿舍里自己组网玩联机游戏?
第6讲 | 交换机与VLAN:办公室太复杂,我要回学校
第7讲 | ICMP与ping:投石问路的侦察兵
第8讲 | 世界这么大,我想出网关:欧洲十国游与玄奘西行
第9讲 | 路由协议:西出网关无故人,敢问路在何方
第二模块 底层网络知识详解:最重要的传输层 (4讲)
第10讲 | UDP协议:因性善而简单,难免碰到“城会玩”
第11讲 | TCP协议(上):因性恶而复杂,先恶后善反轻松
第12讲 | TCP协议(下):西行必定多妖孽,恒心智慧消磨难
第13讲 | 套接字Socket:Talk is cheap, show me the code
第二模块 底层网络知识详解:最常用的应用层 (4讲)
第14讲 | HTTP协议:看个新闻原来这么麻烦
第15讲 | HTTPS协议:点外卖的过程原来这么复杂
第16讲 | 流媒体协议:如何在直播里看到美女帅哥?
第17讲 | P2P协议:我下小电影,99%急死你
第二模块 底层网络知识详解:陌生的数据中心 (6讲)
第18讲 | DNS协议:网络世界的地址簿
第19讲 | HTTPDNS:网络世界的地址簿也会指错路
第20讲 | CDN:你去小卖部取过快递么?
第21讲 | 数据中心:我是开发商,自己拿地盖别墅
第22讲 | VPN:朝中有人好做官
第23讲 | 移动网络:去巴塞罗那,手机也上不了脸书
第三模块 热门技术中的应用:云计算中的网络 (5讲)
第24讲 | 云中网络:自己拿地成本高,购买公寓更灵活
第25讲 | 软件定义网络:共享基础设施的小区物业管理办法
第26讲 | 云中的网络安全:虽然不是土豪,也需要基本安全和保障
第27讲 | 云中的网络QoS:邻居疯狂下电影,我该怎么办?
第28讲 | 云中网络的隔离GRE、VXLAN:虽然住一个小区,也要保护隐私
第三模块 热门技术中的应用:容器技术中的网络 (3讲)
第29讲 | 容器网络:来去自由的日子,不买公寓去合租
第30讲 | 容器网络之Flannel:每人一亩三分地
第31讲 | 容器网络之Calico:为高效说出善意的谎言
第三模块 热门技术中的应用:微服务相关协议 (5讲)
第32讲 | RPC协议综述:远在天边,近在眼前
第33讲 | 基于XML的SOAP协议:不要说NBA,请说美国职业篮球联赛
第34讲 | 基于JSON的RESTful接口协议:我不关心过程,请给我结果
第35讲 | 二进制类RPC协议:还是叫NBA吧,总说全称多费劲
第36讲 | 跨语言类RPC协议:交流之前,双方先来个专业术语表
第四模块 网络协议知识串讲 (4讲)
第37讲 | 知识串讲:用双十一的故事串起碎片的网络协议(上)
第38讲 | 知识串讲:用双十一的故事串起碎片的网络协议(中)
第39讲 | 知识串讲:用双十一的故事串起碎片的网络协议(下)
第40讲 | 搭建一个网络实验环境:授人以鱼不如授人以渔
答疑与加餐 (9讲)
协议专栏特别福利 | 答疑解惑第一期
协议专栏特别福利 | 答疑解惑第二期
协议专栏特别福利 | 答疑解惑第三期
协议专栏特别福利 | 答疑解惑第四期
协议专栏特别福利 | 答疑解惑第五期
加餐1 | 测一测:这些网络协议你都掌握了吗?
加餐2 | 创作故事:我是如何创作“趣谈网络协议”专栏的?
加餐3 | “趣谈网络协议”专栏食用指南
第2季回归 | 这次我们来“趣谈Linux操作系统”
结束语 (1讲)
结束语 | 放弃完美主义,执行力就是限时限量认真完成
趣谈网络协议
登录|注册

第34讲 | 基于JSON的RESTful接口协议:我不关心过程,请给我结果

刘超 2018-08-03
上一节我们讲了基于 XML 的 SOAP 协议,SOAP 的 S 是啥意思来着?是 Simple,但是好像一点儿都不简单啊!
你会发现,对于 SOAP 来讲,无论 XML 中调用的是什么函数,多是通过 HTTP 的 POST 方法发送的。但是咱们原来学 HTTP 的时候,我们知道 HTTP 除了 POST,还有 PUT、DELETE、GET 等方法,这些也可以代表一个个动作,而且基本满足增、删、查、改的需求,比如增是 POST,删是 DELETE,查是 GET,改是 PUT。

传输协议问题

对于 SOAP 来讲,比如我创建一个订单,用 POST,在 XML 里面写明动作是 CreateOrder;删除一个订单,还是用 POST,在 XML 里面写明了动作是 DeleteOrder。其实创建订单完全可以使用 POST 动作,然后在 XML 里面放一个订单
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《趣谈网络协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(23)

  • feifei
    在讨论 RESTful 模型的时候,举了一个库存的例子,但是这种方法有很大问题,那你知道为什么要这样设计吗?

    此方法的问题在于,不是解决问题,而是将数据状态进行了转移,将状态交给存储,这样业务将可以无状态化运行,这种设计可以很好的解决扩展的问题,因为无状态,可以进行负载均衡!使用集群化来解决单机的问题。

    基于文本的 RPC 虽然解决了二进制的问题,但是它本身也有问题,你能举出一些例子吗?

    1,效率问题,程序与文本之间转换效率低,因而不适合内部大数据交换,因为文本利用阅读,对外采用较好

    2,相比于二进制rpc,传输需要的带宽更大,二进制的rpc因为可以使用专用的客户短和服务器代码,可以更好的压缩数据,以提供更大的吞吐量
    2018-08-03
    25
  • kuzan
    crud的语义离业务有点远,客户端往往不想关心crud,客户端关注的语义是业务,比如审批、下单,添加好友。感觉用http这几个method做语义就把服务变成了dao,一个贫血服务
    2018-08-08
    7
  • fsj
    没有restful api之前的json api 是什么样子的?感觉对于客户端同学,不了解之前是什么样子,很难体会到restful api的有点。
    2018-08-08
    6
  • Jay
    题目1:
    库存的问题是:存在并发,导致库存可能为负值。
    用Restful来进行无状态的访问,库存量即状态由业务层来解决。
    题目2:
    用文本来进行RPC的请求和响应,占用的字节数大。
    2018-08-06
    6
  • 阿痕
    能不能谈谈dubbo和springcloud在服务发现方面的优缺点?
    2018-08-03
    6
  • 扬~
    文本传输最终都会转化为二进制流啊,为什么文本要比二进制rpc占用带宽?

    作者回复: 数字2如果用int传输用几个bit,如果是字符串呢?

    2018-11-10
    4
  • blackpiglet
    第一题,我的理解是,资源最终还是有状态的,所以 rest 方式,是把状态转移到了数据库和客户端。那么数据库的抗压能力和稳定性就非常重要了,这也是为什么最近有这么多内存数据库和键值数据库的原因。另外客户端有状态也会造成很多麻烦,毕竟这是不受开发人员控制的,如果逻辑没有切割清楚,升级会非常痛苦。
    第二题,能想到的主要是性能的损耗,毕竟传输的内容更多了,单位带宽下能传输的信息总量会有明显下降。
    2018-08-07
    3
  • 起风了001
    文本传输最终都会转化为二进制流啊,为什么文本要比二进制rpc占用带宽?

    1
    2018-11-10
    作者回复: 数字2如果用int传输用几个bit,如果是字符串呢?

    这个有点疑问, 用int传输需要32或者64位; 字符串的话, 看编码, 如果是utf8编码的话, 还是1个字节8bit即可表示.....

    作者回复: int当然不会用32位编码呀

    2019-05-24
    1
    2
  • jonhey
    看到这里,强烈建议老刘基于此教程,丰富一下内容,写本书,估计能成为网络、云计算、网络编程、微服务领域集大成的经典教材

    作者回复: 不敢不敢

    2019-02-18
    2
  • vic
    楼上那位,登陆动作可以看作是对session的CRUD操作
    2018-12-04
    2
  • leohuachao
    我觉得RESTFul架构流行,也得益于前端框架的丰富吧,要不然维护客户端会话也够难实现

    作者回复: 是的,简单

    2018-09-04
    2
  • 凡凡
    第一个问题有点模糊,感觉这个设计没有问题,任何传输方式,一旦经过网络,都会发生很多可能性,必须做幂等处理。如果指的是服务端无状态的话,原因就是提升扩展性,应对C端用户的大规模和并发。

    第二个问题,主要在于序列化和传输。序列化方面由于有格式就不如二进制紧凑,传输的数据量相对来说要大。另一个是二进制可以自定义规范,或者编码方案,传输路径上,数据被截获,也不容易解析。
    2018-08-03
    2
  • Geek_f6f02b
    RESTful 模型如何实现幂等,这个表示没有想通,就是好比之前SOAP,你告诉我减库存,我就执行减,减后还剩多少,是否成功返回,但是如果是客户端直接减去库存,然后告诉我说,将库存设置成这么多,服务端只要告诉我是否成功,并发了怎么解决,多个人同时请求,如果库存为10,5个请求都是减1,如果前面失败,但是后面成功,前面分别说将库存设置成9、8、7、6,都失败了,最后一个说设置成5成功了,感觉会有问题。

    作者回复: 你这种减是有问题的,并发怎么办,后面5个只有一个成功是对的,其他还可以重试。

    2019-04-25
    1
  • 葱本
    问个问题,购买这个动作,是告诉服务端减一,难受没有办法做到只告诉服务端结果吧

    作者回复: 购买可不止减库存,服务端可以有个状态机的,要不然重复购买怎么办。

    2019-04-04
    1
  • makermade
    讲得很好
    2018-09-27
    1
  • Yayu
    JSON-RESTful 算是一种协议吗?把它理解成一种规范会更好吧?

    作者回复: 没必要纠结吧

    2018-08-15
    1
  • stg609
    想问下,关于库存问题的最终答案在课程哪一讲中有公布吗?
    2019-10-12
  • 随心而至
    底子好,学起什么来都快

    作者回复: 是的

    2019-05-25
  • 起风了001
    我们平时设计的api, 比如购买东西, 是传的数量, 而不是传库存剩余多少呀. 传数量应该是主流才是, 所以传数量不是RESTful模式吗?

    作者回复: 对外接口是,内部实现不是

    2019-05-24
  • 谢晋
    1、库存的扣减,需要考虑幂等性 ,商品的库存也是一种资源,但是好像没有删除库存一说,只有修改和查询。
    2、基于文本的RPC是指的SOAP吗?
    2019-05-12
收起评论
23
返回
顶部