@requestBody 和http请求报文和相应报文

1. @RequestBody 和 @RequestParam

（1）@RequestBody常用于POST请求中，用于接收前台传递得json字符串，且该字符串存在请求体中
（2）@RequestBody 和@RequestParam可以一起使用
（3）@RequestParam 一般用于接收 Get请求参数以及 表单参数
			**特别注意：**

• 如果参数前写了@RequestParam(xxx)，那么前端必须有对应的xxx名字才行(不管其是否有值，当然可以通过设置该注解的required属性来调节是否必须传)，如果没有xxx名的话，那么请求会出错，报400。

• 如果参数前不写@RequestParam(xxx)的话，那么就前端可以有可以没有对应的xxx名字才行，如果有xxx名 的话，那么就会自动匹配；没有的话，请求也能正确发送。

（4）一个请求，只有一个RequestBody；一个请求，可以有多个RequestParam。
（5）通过@RequestBody接收参数时，如果使用对象接收，前台传递得key在对象中不存在时，可以正常访问
（6）特别注意：接收参数时，后台方法中可以不定义接收参数，或者只接收部分参数，请求会正常访问。

最终几个注解解释：
当使用对象接收参数时，可以指定@JsonAlias、@JsonProperty和@JsonIgnore 来简化操作

• @JsonAlias:用于给接收对象得属性起别名，这样前端传递过来得变量名称更灵活
  
  这时，前台通过传递变量名为 Name、name123或者name ，后台接收对象name属性均可以接收到值。
  即： json转模型时，使json中的特定key能转化为特定的模型属性;但是模型转json时，对应的转换后的key仍然与属性名一致。
• @JsonProperty注解，实现：json转模型时，使json中的特定key能转化为指定的模型属性；同样的，模 型转json时，对应的转换后的key为指定的key。
  以下图进一步说明：

此时，json字符串转换为模型时，key为MOTTO的能识别，但key为motto的不能识别。

• @JsonAlias注解需要依赖于setter、getter，而@JsonProperty注解不需要。
• @JsonIgnore注解：
  作用：在实体类向前台返回数据时用来忽略不想传递给前台的属性或接口。
  Eg：Bean实体中会有某些运维字段，在返回信息给前台的时候，当不希望将对应值也一并返回；
  　　此时可以在对应属性上加上注解JsonIgnore或者，可以在User类上加上注解
  　　@JsonIgnoreProperties(value = “{password}”)。

http 请求报文和响应报文

http请求报文组成：

• 请求行
• 请求头
• 请求体

eg:

①是请求方法，GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。不过，当前的大多数浏览器只支持GET和POST，Spring 3.0提供了一个HiddenHttpMethodFilter，允许你通过“_method”的表单参数指定这些特殊的HTTP方法（实际上还是通过POST提交表单）。服务端配置了HiddenHttpMethodFilter后，Spring会根据_method参数指定的值模拟出相应的HTTP方法，这样，就可以使用这些HTTP方法对处理方法进行映射了。

②为请求对应的URL地址，它和报文头的Host属性组成完整的请求URL，③是协议名称及版本号。

④是HTTP的报文头，报文头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息。

⑤是报文体，它将一个页面表单中的组件值通过param1=value1&param2=value2的键值对形式编码成一个格式化串，它承载多个请求参数的数据。不但报文体可以传递请求参数，请求URL也可以通过类似于“/chapter15/user.html? param1=value1&param2=value2”的方式传递请求参数。

常见的HTTP请求报文头属性

• Accept
  请求报文可通过一个“Accept”报文头属性告诉服务端 客户端接受什么类型的响应。

• Cookie
  服务端是怎么知道客户端的多个请求是隶属于一个Session呢？注意到后台的那个jsessionid=5F4771183629C9834F8382E23BE13C4C木有？原来就是通过HTTP请求报文头的Cookie属性的jsessionid的值关联起来的！（当然也可以通过重写URL的方式将会话ID附带在每个URL的后面哦）

• Referer
  表示这个请求是从哪个URL过来的

• Cache-Control
  对缓存进行控制，如一个请求希望响应返回的内容在客户端要被缓存一年，或不希望被缓存就可以通过这个报文头达到目的。

• Content-type
  用于指定提交内容类型，是applicaiton/json 还是 默认得application/x-www-form-urlencoded等，即将参数发送到服务端前，对参数进行编码。

• Http响应头组成

• 响应行

• 响应头

• 响应体

①报文协议及版本；
②状态码及状态描述；
③响应报文头，也是由多个属性组成；
④响应报文体，即我们真正要的“干货”。

• 响应状态码

和请求报文相比，响应报文多了一个“响应状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果。

HTTP的响应状态码由5段组成：

1xx 消息，一般是告诉客户端，请求已经收到了，正在处理，别急…
2xx 处理成功，一般表示：请求收悉、我明白你要的、请求已受理、已经处理完成等信息.
3xx 重定向到其它地方。它让客户端再发起一个请求以完成整个处理。
4xx 处理发生错误，责任在客户端，如客户端的请求一个不存在的资源，客户端未被授权，禁止访问等。
5xx 处理发生错误，责任在服务端，如服务端抛出异常，路由出错，HTTP版本不支持等。

• 常见的HTTP响应报文头属性
• Cache-Control
  响应输出到客户端后，服务端通过该报文头属告诉客户端如何控制响应内容的缓存
• Location
  我们在JSP中让页面Redirect到一个某个A页面中，其实是让客户端再发一个请求到A页面，这个需要Redirect到的A页面的URL，其实就是通过响应报文头的Location属性告知客户端的
• Set-Cookie
  服务端可以设置客户端的Cookie，其原理就是通过这个响应报文头属性实现的
• Content-type
  相应内容得类型