restful风格的好处,REST webservice与普通的servlet有什么不同
restful风格的好处,REST webservice与普通的servlet有什么不同详细介绍
本文目录一览： 为什么说restful更易于实现缓存机制
无状态是针对于“状态”来说的。一个WEB应用协议中的“状态”指的是，为两个相互关联的用户交互操作保留某种公共信息，例如用户登录信息，工作流等。这些信息具有不同作用域，如page，request，session，application等。通常由服务器负责保存这些信息。“无状态”的概念逐渐流行，得益于分布式系统的发展。首先，无状态请求易于实现负载均衡。在分布式web系统下，有多个可用服务器，每个服务器都可以处理客户端请求。传统的有状态请求，因为状态信息只保存在第一次发起请求的那台服务器上，之后的请求都只能由这台服务器来处理，服务器无法自由调度请求。无状态请求则完全没有这个限制。其次，无状态请求有较强的容错性和可伸缩性。如果一台服务器宕机，无状态请求可以透明地交由另一台可用服务器来处理，而有状态的请求则会因为存储请求状态信息的服务器宕机而承担状态丢失的风险。需要注意的是，“状态"指请求的状态，而不是资源的状态。Restful风格的无状态约束要求服务器不保存请求状态，如果确实需要维持用户状态，也应由客户端负责。传递usercredentials是Restful的，而传递sessionID是unRestful的,因为session信息保存在服务器端。
一个好的RESTfulAPI，具备特征
一个好的RESTfulAPI，应该具备以下特征：
这个API应该是对浏览器友好的，能够很好地融入Web，而不是与Web格格不入。
1.浏览器是最常见和最通用的REST客户端。好的RESTfulAPI应该能够使用浏览器HTML完成所有的测试（不需要使用编程语言）。这样的API还可以很方便地使用各种自动化的Web功能测试、性能测试工具来做测试。Web前端应用（基于浏览器的RIA应用、移动App等等）也可以很方便地将多个RESTfulAPI的功能组合起来，建造Mashup类的应用。
这个API中所包含的资源和对于资源的操作，应该是直观和容易理解的，并且符合HTTP协议的要求。
REST开发又被称作“面向资源的开发”，这说明对于资源的抽象，是设计RESTfulAPI的核心内容。RESTfulAPI建模的过程与面向对象建模类似，是以名词为核心的。这些名词就是资源，任何可命名的抽象概念都可以定义为一个资源。而HTTP协议并不是一种传输协议，它实际提供了一个操作资源的统一接口。对于资源的任何操作，都应该映射到HTTP的几个有限的方法（常用的有GET/POST/PUT/DELETE四个方法，还有不常用的PATCH/HEAD/OPTIONS方法）上面。所以RESTfulAPI建模的过程，可以看作是具有统一接口约束的面向对象建模过程。
按照HTTP协议的规定，GET方法是安全且幂等的，POST方法是既不安全也不幂等的（可以用来作为所有写操作的通配方法），PUT、DELETE方法都是不安全但幂等的。将对资源的操作合理映射到这四个方法上面，既不过度使用某个方法（例如过度使用GET方法或POST方法），也不添加过多的操作以至于HTTP的四个方法不够用。
2.如果发现资源上的操作过多，以至于HTTP的方法不够用，应该考虑设计出更多的资源。设计出更多资源（以及相应的URI）对于RESTfulAPI来说并没有什么害处。
这个API应该是松耦合的。
RESTfulAPI的设计包括了三个循序渐进、由低到高的层次：资源抽象、统一接口、超文本驱动。正是这三个层次确保了RESTfulAPI的松耦合性。
3.当设计面向互联网的API时，松耦合变成了一种“必须有”的强需求。紧耦合的API非常脆弱，一旦公布出去，服务器端和客户端都无法持续进化。尤其是服务器端，公布出去的接口根本不敢改，改了之后，几乎所有客户端应用立即无法正常工作。REST这种架构风格就是紧耦合API的解毒剂，这个话题可以谈的很深，这里就不展开了。感兴趣的读者可以参考《REST实战》。
这个API中所使用的表述格式应该是常见的通用格式
在RESTfulAPI中，对于资源的操作，是通过在服务器端-客户端之间传递资源的表述来间接完成的。资源的表述可以有很多种格式，并且在响应和请求中的资源表述格式也会有所不同。GET/POST响应中的资源表述格式，常见的有HTML、XML、JSON；POST/PUT请求中的资源表述格式，常见的有标准的HTML表单参数、XML、JSON。
4.这些常见表述格式，处理起来非常容易，有大量的框架和库提供支持。所以除非有很合理的要求，通常不需要使用自定义的私有格式。
使用HTTP响应状态代码来表达各种出错情况
HTTP响应状态代码，是HTTP协议这个统一接口中用来表达出错情况的标准机制。响应状态代码分成两部分：statuscode和reasonphase。两部分都是可定制的，也可以使用标准的statuscode，只定制reasonphase。
5.如果一个所谓的“RESTfulAPI”对于任何请求都返回200OK响应，在响应的消息体中返回出错情况信息，这种做法显然不符合“确保操作语义的可见性”这个REST架构风格的基本要求。
这个API应该对于HTTP缓存是友好的
6.充分利用好HTTP缓存是RESTfulAPI可伸缩性的根本。HTTP协议是一个分层的架构，从两端的useragent到originserver之间，可以插入很多中间组件。而在整个HTTP通信链条的很多位置，都可以设置缓存。HTTP协议内建有很好的缓存机制，可以分成过期模型和验证模型两套缓存机制。如果API设计者完全没有考虑过如何利用HTTP缓存，那么这个API的可伸缩性会有很多问题。
Restful协议
Representational State Transfer, 是一种软件架构风格，提供一系列限制指导，用于更好的创建 web service 。 符合REST 架构风格的web service 称为Restful web service。
其核心是以 资源 为关注点，而不是方法或消息, RESTful通常是用URL定位资源，HTTP动词（GET, POST, DELETE, PUT等) 描述对资源的操作，该操作过程即改变资源的表现形式，可使用JSON, XML等文件传递该资源操作信息。
Web端主要负责渲染和附带处理简单的商务逻辑，通过Restful API (JSON或其他格式，动词 + 名词)来传递数据和改变数据状态
简要对比下RPC & REST & SOA，不同的服务器向客户端提供服务的方法
SOAP和REST严格来说不是两个对等的概念，可理解为两种服务设计思想和及其具体的实现架构。
二者各有自己的使用场景。如果创建的分布式服务要求较好的安全性，对于传输等底层实现要求较强的可定制性，可以考虑SOAP；如果要求设计实现简单，一般来说安全性要求不高可以考虑REST。这只是一般情况，但偏于面向资源的服务使用REST有天然的优势。
SOAP在.NET中多使用WCF框架，而RESTful则多使用Web API。 具体可参考 Microsoft技术杂志文章
Restful 的好处，无需关注不同的Client等
什么是 restful？
RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。RESTFUL适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。
RESTful架构是对MVC架构改进后所形成的一种架构，通过使用事先定义好的接口与不同的服务联系起来。在RESTful架构中，浏览器使用POST，DELETE，PUT和GET四种请求方式分别对指定的URL资源进行增删改查操作。因此，RESTful是通过URI实现对资源的管理及访问，具有扩展性强、结构清晰的特点。
RESTful架构将服务器分成前端服务器和后端服务器两部分，前端服务器为用户提供无模型的视图；后端服务器为前端服务器提供接口。浏览器向前端服务器请求视图，通过视图中包含的AJAX函数发起接口请求获取模型。
项目开发引入RESTful架构，利于团队并行开发。在RESTful架构中，将多数HTTP请求转移到前端服务器上，降低服务器的负荷，使视图获取后端模型失败也能呈现。但RESTful架构却不适用于所有的项目，当项目比较小时无需使用RESTful架构，项目变得更加复杂。
Swagger整合Jwt授权配置
Swagger 是一个规范和完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务，它有着如下的优点：
1）及时性 (接口变更后，能够及时准确地通知相关前后端开发人员)
2）规范性 (并且保证接口的规范性，如接口的地址，请求方式，参数及响应格式和错误信息)
3）一致性 (接口信息一致，不会出现因开发人员拿到的文档版本不一致，而出现分歧)
4）可测性 (直接在接口文档上进行测试，以方便理解业务)
1）添加pom.xml依赖
io.springfox
springfox-swagger2
2.7.0
io.springfox
springfox-swagger-ui
2.7.0
2）创建swagger配置文件
@Configuration
@EnableSwagger2
public class Swagger2Config {
}3）启动程序
访问路径： http://localhost:8081/swagger-ui.html ，出现生成的文档页面。
此为原生界面，很难看，所以我们需要引入swagger-bootstrap-ui，也就是Knife4j的前身
4）使用Knife4j
a）添加pom.xml依赖
com.github.xiaoymin
knife4j-spring-boot-starter
2.0.7
b）开启Swagger2配置
import java.util.ArrayList;
import java.util.List;
@Configuration
@EnableSwagger2
public class Swagger2Config {
@Bean
public Docket createRestApi() {
return new Docket(DocumentationType.SWAGGER_2)
.pathMapping("/")
.apiInfo(apiInfo())
.select()
//swagger要扫描的包路径
.apis(RequestHandlerSelectors.basePackage("com.dsblog.server.controller"))
.paths(PathSelectors.any())
.build()
}
b）重启服务
访问地址： http://localhost:8081/doc.html ，这个ui界面看起来就更美观，更符合国人的使用习惯
1、添加pom.xml依赖
<project xmlns=" http://maven.apache.org/POM/4.0.0 " xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
xsi:schemaLocation=" http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd ">
4.0.0
2、创建Swagger2Config配置文件
package com.dsblog.server.config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import springfox.documentation.builders.ApiInfoBuilder;
import springfox.documentation.builders.PathSelectors;
import springfox.documentation.builders.RequestHandlerSelectors;
import springfox.documentation.service.*;
import springfox.documentation.spi.DocumentationType;
import springfox.documentation.spi.service.contexts.SecurityContext;
import springfox.documentation.spring.web.plugins.Docket;
import springfox.documentation.swagger2.annotations.EnableSwagger2;
import java.util.ArrayList;
import java.util.List;
@Configuration
@EnableSwagger2
public class Swagger2Config {
@Bean
public Docket createRestApi() {
return new Docket(DocumentationType.SWAGGER_2)
.pathMapping("/")
.apiInfo(apiInfo())
.select()
//swagger要扫描的包路径
.apis(RequestHandlerSelectors.basePackage("com.dsblog.server.controller"))
.paths(PathSelectors.any())
.build()
.securityContexts(securityContexts())
.securitySchemes(securitySchemes());
}
}
3、创建SecurityConfig配置文件
package com.dsblog.server.config.security;
import com.dsblog.server.model.User;
import com.dsblog.server.service.IUserService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.authentication.builders.AuthenticationManagerBuilder;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.builders.WebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.config.http.SessionCreationPolicy;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;
@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {
}
4、创建测试Controller，其中/login登录和/logout退出方法不需要Authorize验证，和上面的重写方法configure(WebSecurity web）匹配，user/info方法需要Authorize验证才能进行访问
package com.dsblog.server.controller;
import com.dsblog.server.model.ResultBean;
import com.dsblog.server.model.User;
import com.dsblog.server.model.UserLoginParam;
import com.dsblog.server.service.IUserService;
import io.swagger.annotations.Api;
import io.swagger.annotations.ApiOperation;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;
import javax.servlet.http.HttpServletRequest;
import java.security.Principal;
@Api(tags = "LoginController")
@RestController
public class LoginController {
}
5、重启程序，输入 http://localhost:8081/doc.html
6、测试
5）携带token发送到后台获取用户信息，验证通过REST webservice与普通的servlet有什么不同
不是同一个层次的东西，不可比
servlet是java定义的一套接口，用于http协议的动态web访问
webservice是一套标准,与语言无关，协议无关，平台无关，基于http协议的远程调用，调用它就像调用本地一个方法一样。就像是我一个.net写的程序调用一个java系统的一个服务。有时候不需要返回什么，仅仅是一个调用方法，方法的参数是一个对象。
万维网联盟指出，REST是一个如何构建Web服务的模型。REST Web是WWW（基于HTTP）的子集，其中代理提供统一的接口语义，本质上是创建，检索，更新和删除，而不是任意或特定于应用程序的接口，并且仅通过交换表示来操纵资源。那么，现在我们知道REST是什么了，作者将简要列出Roy Fielding在其论文的第五章中提到的所有约束：
客户端-服务器：以这样的方式实施服务：将用户界面关注点（客户端获得可移植性）与数据存储关注点（服务器获得可伸缩性）分离开来。无状态：在客户端和服务器之间实现通信时，服务器在处理请求时永远不会利用储存在服务器上下文中的任何信息，而与会话相关的所有信息都存储在客户端中。缓存：当可以（隐式或显式）缓存请求的响应时，客户端应获取缓存的响应。统一接口：所有REST服务都应依赖组件之间相同的统一设计。接口应与提供的服务解耦。分层系统：客户端永远不知道它们是直接连接到服务器还是连接到某些中间服务器。例如，请求可以通过代理，该代理具有负载平衡或共享缓存的功能。
一：Web Service基础知识
一个最简单web服务就一个web页面等待请求与处理。更容易理解的方式是Web
Service可以把一个应用变成一个基本WEB方式的请求与处理的应用。常见的两种
Web Service处理方式为：
a. 基于WSDL/SOAP的方式
b. Rest方式
方式a是比较正统的，客户端调用必须先取得WSDL文件，然后生成调用的API才可
以使用。它不是我要说的重点，基本调用流程如下：
方式b是Rest方式，Rest的Web Service的设计原则是基于CRUD，其支持四种操作分
别为：
GET – 获取信息/请求信息内容，绝大多数浏览器获取信息时使用该方式。
POST – 增加信息内容，显示以前的信息内容，可以看作是insert操作
PUT – 更新信息内容，相当与update
DELETE – 删除信息内容可以看作是delete
Rest方式更加简单便捷，如果从设计原则上看HTTP协议本身已经是最Restful风格的
协议了HTTP协议很好的支持了CRUD的操作。正是因为如此，WEB2.0以来, 基于
Restful的Web Service越来越多的成为首选。
二：认识RestfulStyle
Rest的全称是可表述状态迁移(RepresentationalState Transfer), 可能从字面看有点奇怪
HTTP协议本身无状态协议，其保持连接通过设置请求头字段Connection: keep-alive与
设置过期时间来同时控制。其实Rest方式的WebService也是无状态的这样做的好处最少
有以下两个：
1. 更好的负载平衡，减轻服务器端负担
2. 更快的客户端响应，减少不必要的状态检查。
Restful 风格的兴起，要感谢互联网巨头Google,Facebook等他们提供大量基于Restful
风格的web服务，从谷歌地图到天气预报到翻译，国内的互联网巨头腾讯，新浪微博也
发布自己的web服务，吸引更多的开发者加入他们的阵营。Rest除了满足基本的CRUD
设计原则之外，还要遵循如下约定：
1. 资源操作可以通过描述来实现即Representation
2. 消息本身是无状态与自我描述(传输支持XML与JSON)
3. 可以发送与接受多个Representation
Rest风格(Restful Style)架构原则：
1. 客户服务器方式
2. 无状态协议传输
3. 支持缓存
4. 统一接口定义
5. 分层系统设计
这样发布了Rest的Web服务API其改变不会影响到客户端程序与实现。如果你的系统
不能适用Rest风格的架构怎么办，重新设计一个新的架构，扩展Rest风格架构。但是
这个世界上绝大数的系统与应用要做的事情就是CRUD。
三. Rest与HTTP
上面已经提到过HTTP协议可能是最Rest风格的协议，而HTTP1.1协议设计的一个原则
就要实现Rest风格。所以毫无疑问HTTP的GET, POST, PUT, DELETE就是最好的证明
但是Rest风格是否可以应用到其它一些协议与系统设计中嘛，答案是肯定的，一个最好
的例子证明就POP3协议, POP3支持Fetch 数据记录，查询记录，更新记录与删除记录
(记录代表email)多么完美的Rest风格协议。
已经存在的HTTP协议应用：
1. 浏览器客户端(你天天上网，不是IE就是Chrome，或者其它浏览器，你懂的)
2. 即时消息通信，MSN/Skype支持
3. 各种内容管理系统
4. 博客系统与微博客户端应用。
5. 你可以来补充/？
Rest消息详解:
1. 跟我们现在知道的HTTP URI没有什么分别，Google静态地图就是一个很好的例子
只是URL加上不同参数就可以fetch不同的地图内容。
2. 可以支持任何类型的数据传输，这点与基于XML与JSON的信息传输有点同，后者
更希望传输文本内容与结构化文本内容
3. SOAP与XML-RPC有严格的消息格式限制，rest没有消息格式要求。客户端调用方
便啊！
Rest风格Web服务的好处，显然易见一个好处就是简化了客户端的调用，不再像WSDL
那般麻烦。从而减低第三方开发者的学习成本，减短了学习曲线。有利于服务推广与普
及，吸引更多用户数量从而带来潜在的商业利益。
在软件即服务(SaaS - Software As A Service)与软件即平台(PasS-Platform
As A Service)中有着重要的地位与应用。这正是那些互联网巨头对Rest风
格感兴趣的原因之一。
四：Rest风格架构
Rest风格可以用在非WEB的系统设计与架构中嘛/?打答案是肯定的，Rest可以用在任何
系统设计中，从本质是上Rest不是一种技术，而是一种架构原则，当然可以用来架构非
WEB的系统。系统越大风格越要象Rest方式如此才是一个成功的架构。
WEB中的面向对象编程
ExtJS, KendoUI(基于JQuery)等JavaScript库已经支持非常方便的从URL中fetch内容
更新数据，前端设计越来越趋向于更加细化的分层设计，而不仅仅是MVC。客户端
程序员应该更多的专注前台用户体验，由于这些框架良好的封装与可扩展行，
JavaScript等语言编程越来越多的引入面向对象的概念与实践。可以好不夸张的说如
今的JavaScript编程与十年之前已经有本质不同。
@responsebody一般在什么情况下使用，他的好处与坏处？
@responsebody表示该方法的返回结果直接写入HTTP response body中。
一般在异步获取数据时使用，在使用@RequestMapping后，返回值通常解析为跳转路径，加上@responsebody后返回结果不会被解析为跳转路径，而是直接写入HTTP response body中。比如异步获取json数据，加上@responsebody后，会直接返回json数据。
好处是：GET模式下，这里使用了@PathVariable绑定输入参数，非常适合Restful风格。因为隐藏了参数与路径的关系，可以提升网站的安全性，静态化页面，降低恶意攻击风险。POST模式下，使用@RequestBody绑定请求对象，Spring会帮你进行协议转换，将Json、Xml协议转换成你需要的对象。@ResponseBody可以标注任何对象，由Srping完成对象——协议的转换。
坏处是：返回之前，若前端编码格式不一致，很容易导致乱码。
什么是restful风格的api
微服务有哪些设计原则
微服务应用4个设计原则：
我们总结了四个原则推荐给大家：
AKF拆分原则
前后端分离
无状态服务
Restful通信风格
1.AKF拆分原则
AKF扩展立方体(参考《The Art of Scalability》)，是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。
X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。
Z 轴 ：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。
Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。
场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。
2.前后端分离
前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP ，把Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：
前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。
分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的web UI\ 移动App等访问。
3.无状态服务
对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。
那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
4.Restful通信风格
作为一个原则来讲本来应该是个“无状态通信原则”，在这里我们直接推荐一个实践优选的Restful 通信风格 ，因为他有很多好处：
无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案HTTPS可用。
JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一些RPC框架生态更完善。
当然在有些特殊业务场景下，也需要采用其他的RPC框架，如thrift、avro-rpc、grpc。但绝大多数情况下Restful就足够用了。