http协议put.docx
- 文档编号:4387134
- 上传时间:2022-12-01
- 格式:DOCX
- 页数:4
- 大小:17.78KB
http协议put.docx
《http协议put.docx》由会员分享,可在线阅读,更多相关《http协议put.docx(4页珍藏版)》请在冰豆网上搜索。
http协议put
竭诚为您提供优质文档/双击可除
http协议put
篇一:
http协议
http协议
重要性:
无论是以后用webserverice,还是用rest做大型架构,都离不开对http协议的认识.
甚至可以简化的说:
webservice=http协议+xml
Rest=http协议+json
各种api,也一般是用http+xml/json来实现的.
往小说:
做采集,小偷站,也需要对http协议有所了解,
以及ajax,对http协议有了解之后,学习ajax是非常容易理解的.
什么是协议:
答:
计算机中的协议和现实中的协议是一样的,一式双份/多份.
双方/多方都遵从共同的一个规范,这个规范就可以称为协议.
计算机只所以能全世界互通,协议是功不可没,如果没有协议,计算机各说各话,根本谁都听不懂谁.
ftp,http,stmp,pop,tcp/ip协议.....
http协议的工作流程
当你打开一个页面时,发生了什么
0:
原始状态:
客户端和服务器之间,没有关系.
什么叫连接:
连接就是网络上的虚拟电路.
问:
浏览器能发送http协议,http协议一定要浏览器来发送吗
答:
不是,http既然是一种协议,那么只要满足这种协议,什么工具都可以发.
http请求信息和响应信息的格式
请求:
(1)请求行
(2)请求头信息
(3)请求主体信息(可以没有)
(4)头信息结束后和主体信息之间要空一行请求行又分3部分
请求方法请求路径所用的协议
请求方法:
getpostputdeletetRace,options所用的协议:
目前一般是http/1.1,0.9,1.0已经基本不用.
篇二:
post,get,put等请求方法有什么不同
post,get,put等请求方法有什么不同http1.1的简要介绍
http1.1是一个基于文本的互联网实体信息交互主流协议,这里的实体可以是wap兼容浏览器之类的用户终端,可以是wap网关之类的代理服务器,也可以是javaservlet之类的源服务器程序。
它们之间的交互信息就是两大类:
客户端对服务器端的请求和服务器端对客户端的响应。
一次完整的交互包括一个请求和对它的响应。
所有的请求和响应都采用[RFc822]中定义的标准互联网消息格式,框架如下:
*消息定义
*没有或多个消息头
*cRlF
*可选的消息本体
其中消息定义不分指定了发送消息的类型。
请求和响应都可以包含多个消息头,用来进一步或者重新定义用户终端和服务器之间的交互。
cRlF仅仅用来将信息定义和消息本体分开。
1、请求
在消息定义部分可以这样定义请求:
请求类型uRlhttp/1.1其中请求类型可以是下面的一种:
①.option:
返回请求者和相应者之间可以使用的通信选项,主要用来检测服务器处理能力;
②.get:
获得以uRl标示的文件内容或者程序执行结果。
服务器根据文件名后缀判断服务内容,比如该uRl是静态文本还是一个程序;
③.head:
除了不返回响应的信息本体以外,得到的是跟get一样的信息。
一般用来测试链接的有效性、可达性和近期修改;
④.post:
把消息本体中的消息发送到一个uRl或者其他类似的服务器端定义行为。
通常用来提交一个html表单或者一些数据操作活动;
⑤.put:
把消息本体中的消息发送到一个uRl,跟post类似,但不常用;⑥.delete:
删除uRl指定的资源;
⑦.tRace:
调用一个远程应用层请求消息回路。
发出这个消息的用户终端除了收到原来的消息内容以外,还得到消息在internet上的传送路径。
最常用的请求类型--也是我们在处理wap应用时最关心的--是get和post。
假设有一个wml文档,我们用up的浏览器去浏览的话,就会向服务器发出如下get请求:
gethttp/1.1
accept-charset:
utF-8
accept-language:
ch
accept:
text/vnd.wap.wml,*/*,image/bmp,text/html
user-agent:
up.browser/3.1-upg1up.link/3.2
host:
……
其中粗体的部分是http消息头,这里我们忽略了一些与我们关系不大的消息头。
accept-charset:
用户终端支持的字符集
accept-language:
用户终端目前使用的语言
accept:
用户终端可以接受的mime文件类型
user-agent:
用户终端供应商提供的终端描述信息
host:
请求信息发送到的域名
2、响应
响应的消息定义部分一般是这样的:
http/1.1状态码状态描述在[RFc2616]中定义了近40种不同的状态码。
其中最常见的是3个:
200ok
401unauthorized
404notFound
继续上面那个例子,如果该uRl合法的话,服务器的响应会是这样的:
http/1.1200ok
server:
www/5.0
date:
Fri,26oct200012:
15:
23gmt
connection:
keep-alive
content-length:
1211
content_type:
text/vnd.wap.wml
last-modified:
mon,22oct200018:
19:
24gmt
“http:
///index.wml的源代码。
server:
发出响应的服务器
date:
响应发出的时间
connection:
指示用户终端保持连接
content-length:
响应信息的长度,从deck的第一个" content_type:
响应的mime类型
last-modified:
响应中deck的最后修改时间
当用户终端接收到响应以后,会对其状态信息和消息头进行解码,然后决定对响应做出什么样的动作。
如果收到ok响应,一般会把消息本体里的内容显示在屏幕上。
对于桌面终端,通常是html,对于wap浏览器,则是wml。
http是一种很罗嗦的协议。
即使是简单没有任何数据的请求和响应都要产生数百字节的
消息。
wap通过wap网关来解决这个问题。
wap网关一个很重要的功能就是把所有的http1.1消息转换成无线任务协议的消息格式。
这种格式是压缩的二进制协议,兼容http1.1。
它能解析所有的请求和响应消息,并转换成最精简的bit序列。
到这里我们已经介绍了http1.1的主要内容。
当然http1.1还有很多复杂的内容,但是在这里并不打算多讲,如果你有兴趣,可以去相关网站查找它的资料。
作者只想大家知道一点:
用户终端和服务器之间还有比get和post请求更多的互动消息,它们一样有请求和响应消息头,并且可以包含一些信号来影响wap应用程序的执行和性能。
篇三:
简版http协议接口文档.20xx0407
20xx年3月http短信接口规范v1.2
文档变更记录
目录
1概述...........................................................................................................................................5
1.1
1.2
1.3
1.4
2
3协议说明.......................................................................................................................5适用范围.......................................................................................................................5参考资料.......................................................................................................................5缩略语...........................................................................................................................6通信方式...................................................................................................................................6协议报文定义...........................................................................................................................9
3.1
3.2报文域属性说明...........................................................................................................6消息报文定义...............................................................................................................9
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5下行短信提交mtsmssubmit....................................................................9查询当前预付费用户余额queRyamtF....................................................11上行uRl验证mouRlVeRiFy..................................................................12上行短信推送mosmspush.....................................................................13上行状态报告推送Rptpush.....................................................................14
4附录-码表...............................................................................................................................15
4.1
4.2
4.3
4.4
4.5
认证返回码authstatus............................................................................................15下行短信提交响应码mtrespcode.........................................................................15查询余额响应码queryamtfrespcode..................................................................15上行接收响应码morespcode................................................................................16状态报告stat............................................................................................................16
1概述
1.1协议说明
本短信api是使用http并遵循Rest原则设计的web服务接口,可以使用几乎任何客户端和任何编程语言与Restapi进行交互。
通过发送简单的httppost请求就可以轻松接入使用。
1.1版本说明
在作为cmpp变体的http协议chif1.0推出后,为了简化协议开发难度,对协议的下行和上行部分进行相应地修改,形成本简化协议,保留业务逻辑必要的核心字段,去掉扩展功能的若干字段(本接口不再具备发送数据短信能力)。
1.1与chif1.0的异同:
1.安全认证方式相同,仍然为报文头携带authorization信息base64编码,uRl携带md5token
2.下行mtsmssubmit/上行mosmspush报文简化
3.状态报告推送方式保持不变
4.mo/mt短信内容传递方式不使用byte[],而是使用base64编码的原始utF-8字符串进行传递。
1.2适用范围
1.3参考资料
http1.0
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- http 协议 put