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

百度百科的解释

一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

其中说的设计风格就是rest风格，即Representational State Transfer：表征状态转移。

restful就是把操作的动作交给http的对应方法来识别，get:获取，post:创建，put:更新，delete:删除，这样同一个uri可能标识多个动作。在前台处理方面，其实form表单是只支持get,和post,如果需要支持put、delete等。各个支持rest的框架应该都有处理，比如spring MVC的HiddenHttpMethodFilter就是来解决这个的，也可以ajax处理。

2.为什么要用Rest风格，如果不用Rest的话，接口应该怎么定义，在使用Rest风格之前，大家都是用什么方式写接口的？

在REST之前，用的是RPC(Remote Procedure Call，远程过程调用)和SOAP(Simple Object Access Protocol，简单对象访问协议）。RPC需要设计一些程序嵌入到某种结构中。这种结构需要存储参数、错误的代码、返回值等。SOAP产品的性能开销很大，它是一个巨大的性能杀手。

REST如他字面意思，就是把处理完的数据表征用不同的方法转移到server或者client，通过抽象省去了其他的动作。

Fielding写到：“REST提供了一组架构约束，当作为一个整体来应用时，强调组件交互的可伸缩性、接口的通用性、组件的独立部署、以及用来减少交互延迟、增强安全性、封装遗留系统的中间组件。”

3.了解maven的module。

modules

从字面意思来说，module就是模块，而pom.xml中的modules也正是这个意思，用来管理同个项目中的各个模块；如果maven用的比较简单，或者说项目的模块在pom.xml没进行划分，那么此元素是用不到的；不过一般大一点的项目是要用到的。

如果我们的项目分成了好几个模块，那么我们构建的时候是不是有几个模块就需要构建几次了（到每个模块的目录下执行mvn命令）？当然，你逐个构建没问题，但是非要这么麻烦的一个一个的构建吗，那么简单的做法就是使用聚合，一次构建全部模块。

多模块的好处是你只需在根模块中执行Maven命令，Maven会分别在各个子模块中执行该命令，执行顺序通过Maven的Reactor机制决定。先来看创建Maven多模块工程的常规方法。在我们的示例工程中，存在一个父工程，它包含了两个子工程（模块），一个core模块，一个webapp模块，webapp模块依赖于core模块。这是一种很常见的工程划分方式，即core模块中包含了某个领域的核心业务逻辑，webapp模块通过调用core模块中服务类来创建前端网站。这样将核心业务逻辑和前端展现分离开来，如果之后决定开发另一套桌面应用程序，那么core模块是可以重用在桌面程序中。

4.什么是http协议？Get和post请求有什么区别？http请求content-Type有几种，有什么区别？http适合什么场景？http状态码有哪些？

HTTP协议：Hyper Text Transfer Protocol（超文本传输协议）

HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息。

GET请求 
GET /books/?sex=man&name=Professional HTTP/1.1 
Host: www.wrox.com 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) 
Gecko/20050225 Firefox/1.0.1 
Connection: Keep-Alive 
注意最后一行是空行

POST请求 
POST / HTTP/1.1 
Host: www.wrox.com 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) 
Gecko/20050225 Firefox/1.0.1 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 40 
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley 
1、GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，多个参数用&连接；例 如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

POST提交：把提交的数据放置在是HTTP包的包体中。上文示例中红色字体标明的就是实际的传输数据

因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变 
2、传输数据的大小：首先声明：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。

而在实际开发中存在的限制主要有：

GET:特定浏览器和服务器对URL长度有限制，例如 IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系 统的支持。

因此对于GET提交时，传输数据就会受到URL长度的 限制。

POST:由于不是通过URL传值，理论上数据不受 限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。

3、安全性

POST的安全性要比GET的安全性高。比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存；(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击

4、Http get,post,soap协议都是在http上运行的

（1）get：请求参数是作为一个key/value对的序列（查询字符串）附加到URL上的 
查询字符串的长度受到web浏览器和web服务器的限制（如IE最多支持2048个字符），不适合传输大型数据集同时，它很不安全

（2）post：请求参数是在http标题的一个不同部分（名为entity body）传输的，这一部分用来传输表单信息，因此必须将Content-type设置为:application/x-www-form- urlencoded。post设计用来支持web窗体上的用户字段，其参数也是作为key/value对传输。 
但是：它不支持复杂数据类型，因为post没有定义传输数据结构的语义和规则。

（3）soap：是http post的一个专用版本，遵循一种特殊的xml消息格式 
Content-type设置为: text/xml 任何数据都可以xml化。

Http协议定义了很多与服务器交互的方法，最基本的有4种，分别是GET,POST,PUT,DELETE. 一个URL地址用于描述一个网络上的资源，而HTTP中的GET, POST, PUT, DELETE就对应着对这个资源的查，改，增，删4个操作。 我们最常见的就是GET和POST了。GET一般用于获取/查询资源信息，而POST一般用于更新资源信息.

我们看看GET和POST的区别

GET提交的数据会放在URL之后，以?分割URL和传输数据，参数之间以&相连，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的数据放在HTTP包的Body中.

GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制.

GET方式需要使用Request.QueryString来取得变量的值，而POST方式通过Request.Form来获取变量的值。

GET方式提交数据，会带来安全问题，比如一个登录页面，通过GET方式提交数据时，用户名和密码将出现在URL上，如果页面可以被缓存或者其他人可以访问这台机器，就可以从历史记录获得该用户的账号和密码。

至于content-type的类型，http头部字段Content-Type约定请求和响应的HTTP body内容编码类型，客户端和服务端根据http头部字段Content-Type正确解码HTTP body内容。 
这篇博客讲的比较清楚。 
https://blog.csdn.net/blueheart20/article/details/45174399

http适用的场景：公司OA服务，互联网服务。 
提供适合“请求-相应”模式功能的场景。

Http状态码：

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

1xx：指示信息–表示请求已接收，继续处理 
2xx：成功–表示请求已被成功接收、理解、接受 
3xx：重定向–要完成请求必须进行更进一步的操作 
4xx：客户端错误–请求有语法错误或请求无法实现 
5xx：服务器端错误–服务器未能实现合法的请求

5.什么是tcp/ip协议？TCP的三次握手指的是什么，为什么一定要三次握手，而不是四次或者是两次？

这个我自己讲过小课堂，简书地址： 
https://www.jianshu.com/p/e4b85cbbe777 
这里件要说下。

• IP 是无连接的通信协议,用于计算机之间的通信。
• TCP 用于应用程序之间的通信,使用固定的连接。
• TCP/IP 意味着 TCP 和 IP 在一起协同工作。 
  TCP 负责应用软件（比如你的浏览器）和网络软件之间的通信。 
  IP 负责计算机之间的通信。 
  TCP 负责将数据分割并装入 IP 包，然后在它们到达的时候重新组合它们。 
  IP 负责将包发送至接受者。

建立TCP/IP的过程就是要讲的三次握手。 
即三次握手就是为了解决连接的问题 
建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。

（1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

（2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

（3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

6.什么是WEBService，实现WEBService有哪些框架，为什么WEBService经常被认为太重了，只有银行和大型国企才会使用的更多有一些？

WebService是一种跨编程语言和跨操作系统平台的远程调用技术。

目前开发Web Service的几个框架：Axis，axis2，Xfire，CXF以及JWS。其中，以axis2与cxf所最为常用，Axis与XFire已随着技术不断的更替慢慢落幕，而目前也只有axis2和cxf官方有更新，Axis与XFire都已不再更新。

WEBservice不适用的情况：目前，企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下，最好就不要用WebService，只要用本地的 API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用。当然WebService也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。

7.Spring MVC和Struts的区别是什么，为什么更倾向于使用Spring MVC？

没用过struts 
https://blog.csdn.net/dove_knowledge/article/details/53354491 
不过springMVC对spring更友好

8.web.xml里的主要配置都包括什么，都代表什么含义，比如怎么加载Spring 配置的？

web.xml文件是Java web项目中的一个配置文件，主要用于配置欢迎页、Filter、Listener、Servlet等，但并不是必须的，一个java web项目没有web.xml文件照样能跑起来。 
web.xml文件加载顺序为：(与xml中的书写顺序无关) 
ServletContext -> context-param -> listener -> filter -> servlet 
具体的各个标签：https://segmentfault.com/a/1190000011404088

9.Annotation和XML两种配置的差别，为什么更喜欢使用Annotaion来配置Spring MVC？

注解与XML配置的区别

注解：是一种分散式的元数据，与源代码紧绑定。

xml：是一种集中式的元数据，与源代码无绑定。

因此注解和XML的选择上可以从两个角度来看：分散还是集中，源代码绑定/无绑定。

注解的缺点：

1、很多朋友比如在使用spring注解时，会发现注解分散到很多类中，不好管理和维护；这个其实要借助工具，我目前使用的是IDEA，它在这方面表现的非常好；当然现在还有Spring的STS，也是不错的； 所以借助工具，能解决这个问题；

2、注解的开启/关闭必须修改源代码，因为注解是源代码绑定的，如果要修改，需要改源码，这个有这个问题，所以如果是这种情况，还是使用XML配置方式；比如数据源；

3、注解还一个缺点就是灵活性，比如在之前翻译的Spring Framework 4.0 M1: WebSocket 支持；在实现复杂的逻辑上，没有XML来的更加强大；注解就是要么用，要么不用，比如之前的jpa bean validation，要么全，要么没；遇到这种情况很痛苦；

4、还一种就是约定大于配置，但是在处理一些复杂的情况下，注解还是需要的（如Spring的数据验证/数据绑定注解很强大）；

5、通用配置还是走XML吧，比如事务配置，比如数据库连接池等等，即通用的配置集中化，而不是分散化，如很多人使用@Transactional来配置事务，在很多情况下这是一种太分散化的配置；

6、XML方式比注解的可扩展性和复杂性维护上好的多，比如需要哪些组件，不需要哪些；在面对这种情况，注解扫描机制比较逊色，因为规则很难去写或根本不可能写出来；

注解的好处：

1、XML配置起来有时候冗长，此时注解可能是更好的选择，如jpa的实体映射；注解在处理一些不变的元数据时有时候比XML方便的多，比如springmvc的数据绑定，如果用xml写的代码会多的多；

2、注解最大的好处就是简化了XML配置；其实大部分注解一定确定后很少会改变，所以在一些中小项目中使用注解反而提供了开发效率，所以没必要一头走到黑；

3、注解相对于XML的另一个好处是类型安全的，XML只能在运行期才能发现问题。

注解也好，XML也好，我们还是需要一些开关/替换机制来控制特殊需求，以改变那种要么全部 要么没有的方案。。

还一种呼声就是约定大于配置，这种方案可能在某些场景下是最优的，但是遇到一些复杂的情况可能并不能解决问题，所以此时注解也是一个不错的方案。尤其在使用springmvc时，好处是能体会的出的。

不管使用注解还是XML，做的事情还是那些事情，但注解和XML都不是万能的，满足自己的需求且已一种更简单的方式解决掉问题即可。

就像探讨一下技术问题，很多人都带有很强的个人喜好来评判一个东西的好坏，这种探讨没有任何意义，我们最终的目的是解决方案，所以我们应该探讨的是能不能解决问题，能不能以更容易理解的方式解决问题，能不能更简单的解决问题。

不管是约定大于配置、注解还是XML配置也好，没有哪个是最优的，在合适的场景选择合适的解决方案这才是重要的。就像设计模式一样：是对特定环境中重复出现的特定问题的一个经过前人验证了的解决方案。