今天完成的任务：学习深度思考

50.Content-type中的数据类型，在Spring MVC中都怎么接收数据？ 

1.  Content-Type

  MediaType，即是Internet Media Type，互联网媒体类型；也叫做MIME类型，在Http协议消息头中，使用Content-Type来表示具体请求中的媒体类型信息。

 常见的媒体格式类型如下：

    text/html ： HTML格式

    text/plain ：纯文本格式     

    text/xml ：  XML格式

    image/gif ：gif图片格式   

    image/jpeg ：jpg图片格式

    image/png：png图片格式

   以application开头的媒体格式类型：

   application/xhtml+xml ：XHTML格式

   application/xml     ： XML数据格式

   application/atom+xml  ：Atom XML聚合格式   

   application/json    ： JSON数据格式

   application/pdf       ：pdf格式 

   application/msword  ： Word文档格式

   application/octet-stream ： 二进制流数据（如常见的文件下载）

   application/x-www-form-urlencoded ： <form encType=””>中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）

   另外一种常见的媒体格式是上传文件之时使用的：

    multipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式

     以上就是我们在日常的开发中，经常会用到的若干content-type的内容格式。

2.   Spring MVC中关于关于Content-Type类型信息的使用

    首先我们来看看RequestMapping中的Class定义：

@Target({ElementType.METHOD, ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

@Documented

@Mapping

public @interface RequestMapping {

      String[] value() default {};

      RequestMethod[] method() default {};

      String[] params() default {};

      String[] headers() default {};

      String[] consumes() default {};

      String[] produces() default {};

}

value:  指定请求的实际地址， 比如 /action/info之类。

method：  指定请求的method类型， GET、POST、PUT、DELETE等

consumes： 指定处理请求的提交内容类型（Content-Type），例如application/json, text/html;

produces:    指定返回的内容类型，仅当request请求头中的(Accept)类型中包含该指定类型才返回

params： 指定request中必须包含某些参数值是，才让该方法处理

headers： 指定request中必须包含某些指定的header值，才能让该方法处理请求

其中，consumes， produces使用content-typ信息进行过滤信息；headers中可以使用content-type进行过滤和判断。

51.什么是restful？rest的请求方法有哪些，有什么区别？

为什么用RESTful结构?

曾经,网页是前端后端不分离的，比如之前的PHP，JSP等,这个在之前的桌面时代问题尚且不大，但是近年来移动互联网的发展，各种类型的Client层出不穷，这种模式就很僵硬了.

因此更为合理的RESTful应运而生,它可以通过一套统一的接口为 Web，iOS和Android等提供服务。另外对于广大平台来说，比如Facebook platform，微博开放平台，微信公共平台等，它们不需要有显式的前端，只需要一套提供服务的接口，于是RESTful更是它们最好的选择。

REST是什么?是如何提出的?

REST全称是resource representational state,表现层状态转化,这不好理解,因此用另一句话概括:

URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。

REST全称是resource representational state,表现层状态转化.

它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。

REST指的是一组架构约束条件和原则。" 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。

REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束.

[资源resource]

REST的名称"表现层状态转化"中，省略了主语. "表现层"其实指的是"资源"（Resources）的"表现层".

所谓资源,是网络上的一个具体信息,它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实体。本质上就是数据,是网络的核心.

例如:

某用户的手机号码

某用户的个人信息

最多用户订购的GPRS套餐

两个产品之间的依赖关系

某用户可以办理的优惠套餐

楼主,求资源. 这里的"资源"也是属于资源的范畴.

[统一标识符URI]

要让一个资源可以被识别,需要有个独一无二标识,在WEB中这个唯一标识就是URI(Unriform Resource Identifier)

URI既可以看成是资源的地址,也可以看成是资源的名称,如果某些信息没有使用URI来表示那就不能算是一个"资源",只能算是资源的一些信息.

[表现层]

资源是一种信息实体,它可以有多种外在表现形式;把"资源"具体呈现出来的方式叫做它的"表现层".

比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。

[状态转化]

访问一个资源,就代表了客户端和服务端一个互动过程,在这个过程中势必涉及到数据和状态的变化.

如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。

GET用来获取资源,对应着查询.

POST用来新建资源（也可以用于更新资源）,对应着新增.

PUT用来更新资源,对应着更改.

DELETE用来删除资源,对应删.

他们在安全性,幂等性上都有差别.

(幂等性:对同一REST接口的多次访问,得到的结果是相同的.

安全性:对该REST接口访问,不会使服务器端资源的状态发生改变,换句话说,请求一般不产生副产物.)

GET - 提供的资源的只读访问。最常用于向服务器查询某些信息,必要时可将查询字符串参数追加到URL末尾,以便将信息发送给服务器.

安全且幂等

PUT -在REST中主要用于更新资源,因为大多数浏览器不支持put和delete,会自动将put和delete请求转换get和post,因此为了使用put和delete方法需要以post发送请求,在表单中使用隐藏域发送真实请求。

不安全但幂等

DELETE - 用于删除资源。

不安全但幂等.

POST - 用于更新现有资源或创建新的资源。

不安全且不幂等.

区别:

POST与SET

POST方法提交的数据放置在HTTP报文实体的主体里,所以相比GET方法而言,POST方法安全性更高.

GET方法传输的数据量一般限制在2KB,而POST方法对于数据大小是无限制的.

POST与PUT

最大的区别:PUT是幂等的,即多次调用不应产生副作用,而POST不幂等.

URI的设计原则:

最重要的:可寻址性原则,要具有自描述性,要易读.

例如分析github的一些uri设计:

https://github.com/git

https://github.com/git/git

https://github.com/git/git/blob/master/block-sha1/sha1.h

https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08

https://github.com/git/git/pulls

https://github.com/git/git/pulls?state=closed

https://github.com/git/git/compare/master…next

总结技巧就是:

使用_或-来让URI可读性更好

曾经Web上的URI都是冰冷的数字或者无意义的字符串，但现在越来越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。 例如开源中国社区，它上面的新闻地址就采用这种风格

http://www.oschina.net/news/38119/oschina-translate-reward-plan。

使用/来表示资源的层级关系

例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示一个多级的资源， 指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。

使用?用来过滤资源

很多人只是把?简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把?用于对资源的过滤， 例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求， 这种URL通常对应的是一些特定条件的查询结果或算法运算结果。

可以用,或;表示同级资源的关系

有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作为URI。 不过，现在github是使用…来做这个事情的，例如/git/git/compare/master…next。

什么是无状态?

无状态原则是RESTful架构设计中一个非常重要的原则,无状态是相对于有状态而言的.状态指的是请求的状态,在无状态的Web服务中,每一个Web请求都必须是独立的,请求之间是完全分离的,Server没有保存Client的状态信息,所以Client发送的请求必须包含有能够让服务器理解请求的全部信息,使得一个Client的Web请求能够被任何可用的Server应答;而有状态的请求的状态信息只保存在第一次接受请求的Server上,所以后来同一个Client的请求都只能由这一台Server来处理.

无状态的请求有利于实现均衡负载.

restful的好处?

REST极大降低沟通复杂度,通过把表征作为唯一的沟通方式,无需去讨论过程而只需讨论表征.

URL具有很强可读性的，具有自描述性；

资源描述与视图的松耦合；

可提供OpenAPI，便于第三方系统集成，提高互操作性；

如果提供无状态的服务接口，可提高应用的水平扩展性；

明天的计划：学习任务三