前面两篇讲解了Spring-Web对HTTP中基本概念的抽象过程，但在交互过程中都会存在下面两种通用的角色：服务端、客户端，不同的角色对于请求（信息）的关注点是不一样的，那我们就看看在Spring-Web中它所理解的服务端和客户端的分别会关注哪些信息，以及怎么对基于HTTP协议的服务端和客户端进行抽象，这一篇先说一下对服务端的抽象。
对服务端的抽象
服务端主要的关注点就是对请求的处理和生成响应，所以关注的对象也非常大的明确就是请求和响应，另外对于请求来说一个关键的信息就是URI，即请求地址，所以在Spring-Web中对请求的地址也做了相应的抽象。
对请求的抽象
接口org.springframework.http.server.ServerHttpRequest代表了服务端的请求，也就是站在服务端的角度来看请求。
ServerHttpRequest接口继承了HttpRequest和HttpInputMessage两个接口，非常清晰的表明ServerHttpRequest也是一种HttpRequest（虽然写出来像废话，但作为程序设计非常有用），并且是基于HTTP协议的输入信息，这个应该很好理解，请求对于服务端来说就是输入信息。
在ServerHttpRequest接口中，主要关心以下内容：
1、认证信息（Principal）
2、本地地址（LocalAddress），即接收请求的服务器地址
3、远程地址（RemoteAddress），即客户端的地址
4、异步请求的控制信息（待探究）
对响应的抽象
接口org.springframework.http.server.ServerHttpResponse代表了服务端返回给客户端的响应。
ServerHttpResponse接口继承了HttpOutputMessage、Flushable和Closeable三个接口，其中，
HttpOutputMessage表明了ServerHttpResponse是基于HTTP协议的输出信息，这个应该也很好理解，响应对于服务端来说就是输出信息，输出给客户端；
Flushable是java.io包的接口，表明数据源或数据目的地的数据是可以被“冲刷”的，即强迫把缓存区的数据全部输出；
Closeable接口也是java.io包的接口，表明数据源或数据目的地的数据是可以被“关闭”的，即释放资源。
对URI的抽象
在Spring-Web中，对URI的抽象是通过一下两个接口来实现的：
org.springframework.http.server.PathContainer，下面的截图是源代码中对这个接口的说明，大概意思就是该接口是一个URI的结构化的代表，对URI的路径进行了预处理，将其转化成了分隔符(Separator)和路径段（PathSegment）序列（即有多个，并有顺序），其中Separator和PathSegment也是两个接口，并且是PathContainer的内部接口。
org.springframework.http.server.RequestPath接口，继承了PathContainer，代表了一个完整的请求路径，它将路径分为了两大部分，一部分就是ContextPath,即代表了一个应用，第二部分就是除去ContextPath的剩余部分。
