Get：是以实体的方式得到由请求URI所指定资源的信息，如果请求URI只是一个数据产生过程，那么最终要在响应实体中返回的是处理过程的结果所指向的资源，而不是处理过程的描述。
Post：用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列中请求URI所指定资源的附加新子项，Post被设计成用统一的方法实现下列功能：
1：对现有资源的解释
2：向电子公告栏、新闻组、邮件列表或类似讨论组发信息。
3：提交数据块
4：通过附加操作来扩展数据库
从上面描述可以看出，Get是向服务器发索取数据的一种请求；而Post是向服务器提交数据的一种请求，要提交的数据位于信息头后面的实体中。
Get：是以实体的方式得到由请求URI所指定资源的信息，如果请求URI只是一个数据产生过程，那么最终要在响应实体中返回的是处理过程的结果所指向的资源，而不是处理过程的描述。
Post：用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列中请求URI所指定资源的附加新子项，Post被设计成用统一的方法实现下列功能：
1：对现有资源的解释
2：向电子公告栏、新闻组、邮件列表或类似讨论组发信息。
3：提交数据块
4：通过附加操作来扩展数据库
从上面描述可以看出，Get是向服务器发索取数据的一种请求；而Post是向服务器提交数据的一种请求，要提交的数据位于信息头后面的实体中。
post，get，put等请求方法有什么不同
HTTP 1.1的简要介绍 HTTP 1.1是一个基于文本的互联网实体信息交互主流协议，这里的实体可以是WAP兼容浏览器之类的用户终端，可以是WAP网关之类的代理服务器，也可以是 Java servlet之类的源服务器程序。它们之间的交互信息就是两大类：客户端对服务器端的请求和服务器端对客户端的响应。一次完整的交互包括一个请求和对它 的响应。 所有的请求和响应都采用[RFC822]中定义的标准互联网消息格式，框架如下： * 消息定义 * 没有或多个消息头 * CRLF * 可选的消息本体 其中消息定义不分指定了发送消息的类型。请求和响应都可以包含多个消息头，用来进一步或者重新定义用户终端和服务器之间的交互。CRLF仅仅用来将信息定义和消息本体分开。 1、 请求 在消息定义部分可以这样定义请求： 请求类型 URL HTTP/1.1 其中请求类型可以是下面的一种： ①. OPTION：返回请求者和相应者之间可以使用的通信选项，主要用来检测服务器处理能力； ②. GET：获得以URL标示的文件内容或者程序执行结果。服务器根据文件名后缀判断服务内容，比如该URL是静态文本还是一个程序； ③. HEAD：除了不返回响应的信息本体以外，得到的是跟GET一样的信息。一般用来测试链接的有效性、可达性和近期修改； ④. POST：把消息本体中的消息发送到一个URL或者其他类似的服务器端定义行为。通常用来提交一个HTML表单或者一些数据操作活动； ⑤. PUT：把消息本体中的消息发送到一个URL，跟POST类似，但不常用； ⑥. DELETE：删除URL指定的资源； ⑦. TRACE：调用一个远程应用层请求消息回路。发出这个消息的用户终端除了收到原来的消息内容以外，还得到消息在Internet上的传送路径。 最常用的请求类型--也是我们在处理WAP应用时最关心的--是GET和POST。假设有一个WML文档，我们用UP的浏览器去浏览的话，就会向服务器发出如下GET请求： GET www.wap86.com/index.wml HTTP/1.1 accept-charset: UTF-8 accept-language: ch accept: text/vnd.wap.wml, */*, image/bmp, text/html user-agent: UP.Browser/3.1-UPG1 UP.Link/3.2 host: www.wap86.net …… 其中粗体的部分是HTTP消息头，这里我们忽略了一些与我们关系不大的消息头。 accept-charset: 用户终端支持的字符集 accept-language: 用户终端目前使用的语言 accept: 用户终端可以接受的MIME文件类型 user-agent: 用户终端供应商提供的终端描述信息 host: 请求信息发送到的域名 2、 响应 响应的消息定义部分一般是这样的：HTTP/1.1 状态码 状态描述 在[RFC2616]中定义了近40种不同的状态码。其中最常见的是3个： 200 OK 401 Unauthorized 404 Not Found 继续上面那个例子，如果该URL合法的话，服务器的响应会是这样的： HTTP/1.1 200 OK Server: www/5.0 Date: Fri, 26 Oct 2000 12:15:23 GMT Connection: Keep-Alive Content-Length: 1211 Content_Type: text/vnd.wap.wml Last-Modified: Mon, 22 Oct 2000 18:19:24 GMT <?xml version=”1.0”> <!<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” “http://www.wapforum.org/DTD/wml_1.1.xml”> …… 其它内容 …… 这个响应信息里包括了响应的数字代码和文本描述，然后是一组消息头。在一个换行符以后就是消息本体，在这里，消息本体就是www.wap86.net/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应用程序的执行和性能。
Post：用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列中请求URI所指定资源的附加新子项，Post被设计成用统一的方法实现下列功能：
1：对现有资源的解释
2：向电子公告栏、新闻组、邮件列表或类似讨论组发信息。
3：提交数据块
4：通过附加操作来扩展数据库
从上面描述可以看出，Get是向服务器发索取数据的一种请求；而Post是向服务器提交数据的一种请求，要提交的数据位于信息头后面的实体中。
Get：是以实体的方式得到由请求URI所指定资源的信息，如果请求URI只是一个数据产生过程，那么最终要在响应实体中返回的是处理过程的结果所指向的资源，而不是处理过程的描述。
Post：用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列中请求URI所指定资源的附加新子项，Post被设计成用统一的方法实现下列功能：
1：对现有资源的解释
2：向电子公告栏、新闻组、邮件列表或类似讨论组发信息。
3：提交数据块
4：通过附加操作来扩展数据库
从上面描述可以看出，Get是向服务器发索取数据的一种请求；而Post是向服务器提交数据的一种请求，要提交的数据位于信息头后面的实体中。
post，get，put等请求方法有什么不同
HTTP 1.1的简要介绍 HTTP 1.1是一个基于文本的互联网实体信息交互主流协议，这里的实体可以是WAP兼容浏览器之类的用户终端，可以是WAP网关之类的代理服务器，也可以是 Java servlet之类的源服务器程序。它们之间的交互信息就是两大类：客户端对服务器端的请求和服务器端对客户端的响应。一次完整的交互包括一个请求和对它 的响应。 所有的请求和响应都采用[RFC822]中定义的标准互联网消息格式，框架如下： * 消息定义 * 没有或多个消息头 * CRLF * 可选的消息本体 其中消息定义不分指定了发送消息的类型。请求和响应都可以包含多个消息头，用来进一步或者重新定义用户终端和服务器之间的交互。CRLF仅仅用来将信息定义和消息本体分开。 1、 请求 在消息定义部分可以这样定义请求： 请求类型 URL HTTP/1.1 其中请求类型可以是下面的一种： ①. OPTION：返回请求者和相应者之间可以使用的通信选项，主要用来检测服务器处理能力； ②. GET：获得以URL标示的文件内容或者程序执行结果。服务器根据文件名后缀判断服务内容，比如该URL是静态文本还是一个程序； ③. HEAD：除了不返回响应的信息本体以外，得到的是跟GET一样的信息。一般用来测试链接的有效性、可达性和近期修改； ④. POST：把消息本体中的消息发送到一个URL或者其他类似的服务器端定义行为。通常用来提交一个HTML表单或者一些数据操作活动； ⑤. PUT：把消息本体中的消息发送到一个URL，跟POST类似，但不常用； ⑥. DELETE：删除URL指定的资源； ⑦. TRACE：调用一个远程应用层请求消息回路。发出这个消息的用户终端除了收到原来的消息内容以外，还得到消息在Internet上的传送路径。 最常用的请求类型--也是我们在处理WAP应用时最关心的--是GET和POST。假设有一个WML文档，我们用UP的浏览器去浏览的话，就会向服务器发出如下GET请求： GET www.wap86.com/index.wml HTTP/1.1 accept-charset: UTF-8 accept-language: ch accept: text/vnd.wap.wml, */*, image/bmp, text/html user-agent: UP.Browser/3.1-UPG1 UP.Link/3.2 host: www.wap86.net …… 其中粗体的部分是HTTP消息头，这里我们忽略了一些与我们关系不大的消息头。 accept-charset: 用户终端支持的字符集 accept-language: 用户终端目前使用的语言 accept: 用户终端可以接受的MIME文件类型 user-agent: 用户终端供应商提供的终端描述信息 host: 请求信息发送到的域名 2、 响应 响应的消息定义部分一般是这样的：HTTP/1.1 状态码 状态描述 在[RFC2616]中定义了近40种不同的状态码。其中最常见的是3个： 200 OK 401 Unauthorized 404 Not Found 继续上面那个例子，如果该URL合法的话，服务器的响应会是这样的： HTTP/1.1 200 OK Server: www/5.0 Date: Fri, 26 Oct 2000 12:15:23 GMT Connection: Keep-Alive Content-Length: 1211 Content_Type: text/vnd.wap.wml Last-Modified: Mon, 22 Oct 2000 18:19:24 GMT <?xml version=”1.0”> <!<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN” “http://www.wapforum.org/DTD/wml_1.1.xml”> …… 其它内容 …… 这个响应信息里包括了响应的数字代码和文本描述，然后是一组消息头。在一个换行符以后就是消息本体，在这里，消息本体就是www.wap86.net/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应用程序的执行和性能。
扫一扫
6668
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
