关于Spring Boot的故事

好的，上次我们通过Swagger生成了服务器的存根。不过，我们还没有解释代码之类的内容。事实上，上一次生成的代码是用SpringBoot来运行的。这一次，我们将简单介绍一下SpringBoot的概述，并进行一些小的修改，来进行开发工作的模拟体验。

像往常一样，这篇文章中会涉及一些与事实不同的内容。这是基于我的理解角度来谈论的。请理解我会适当地概括事实并以易于理解的方式记录下来。

作业范围

Spring Boot是什么？

我们现在就直接进入正题吧。Spring Boot1是什么呢？让我们看一下项目网站的概述吧。

Spring Boot让您轻松创建独立的、生产级的基于Spring的应用程序，可以直接运行。

啊，是啊。完全就是这样。“它是一个非常方便的软件，可以将使用Spring（框架）的应用程序仅仅通过一次‘run’调用就打包成可以运行的状态。”是的，确实完全一样。只要看到这种网站的标题，就会立刻想到“是的，没错”，这样一来就会感觉自己已经略有掌握了这项技术。

顺便说一下，Spring Boot 是基于 Spring 的……就像 GNU is Not Unix 这样的东西。Spring Boot 对于 Spring 的定义是怎样的呢！嗯，虽然 Spring Boot 和 Spring 是不同的东西，但它们之间有一些区别。

就是这样。让我们从那里开始吧。

Spring Framework的产生和成功

这段时间发生了一些事情，虽然已经是很久以前的事了，初到2000年代初期，一些无法再忍受长期维持主机计算机成本（硬件和COBOL人员供应）的企业开始转向开放环境。在这个时期，这些企业在选择转向开放环境的目标时遇到了很多困难。在此之前，用户们被局限在“主机”的框架中，被迫沉默地不断购买机器，这种过度意识是他们当时的现状。

• 可搬性

要員確保の容易さ

这是Java概念“Write once run anywhere（一次编写，到处运行）”的高度契合。因此，Java也致力于这个市场。它配备了分布式事务、消息传递、安全等功能，并制定了面向企业市场的J2EE作为标准规范。然后，推出了两个实现产品。

Java企业版的错误计算

Java EE是一个高度完善的规范。但是，它对于想做的事情来说有一种过度规格的感觉。尤其是Enterprise Java Beans不受欢迎，无论是要使用XA事务还是不使用，都必须使用这个规范来编写（所以很多企业都总结出这个结论）。除了Java SE规范外，还必须理解Java EE规范才能编写。而要理解这个规范，需要在J2EE环境中进行实际操作和验证。哎呀，怎么好像人员招聘变得这么容易了？这些矛盾以及当时计算资源的匮乏加在一起，使得它变得非常不受欢迎。特别是，

• デプロイにめちゃくちゃ時間かかる（分オーダー）

学習コスト（時間もお金も）かかる

这两个因素非常重要，被称为重型容器。(Zhè gè ,

Spring Framework的概念

对这种情况作出回应的是当时的Spring Framework。现在也许很难相信，但在上世纪90年代，Java在Web领域的应用优势超过了企业领域。当时，动态Web领域中普遍采用用Perl通过CGI（通用网关接口）来接收的方式，但作为支撑大规模Web的基础设施，存在一些问题。其中最典型的是

HTTPの問い合わせが発生する度にPerlパーサが起動する。

使用Java的回答是Servlet容器，它是一个服务器进程，可以在完成包括数据库连接在内的所有准备工作后处理HTTP请求，避免了每次请求都启动解析器进程和建立数据库连接的开销。当时，这是一个非常有效的解决方案。作为Servlet容器的开源实现，Tomcat被提供了出来。即使在Servlet被整合到J2EE之后，Tomcat仍选择保持作为独立的Servlet容器，并放弃了采用EJB1.2等技术。

Spring Framework发现了这个问题。J2EE太“笨重”了，但希望能有处理HTTP的能力。恰好，Tomcat在这方面非常擅长。“对了，我们可以以Tomcat为基础来整合功能。”基于这个理念，我们开发了Spring Framework，加入了最基本必要的RPC等功能。这一尝试非常成功，对于JavaEE的“重型”容器来说，它变成了被称之为“轻量级”容器的Spring Framework。

春季启动爆发！

Spring Framework 可以实现从界面操作到事务处理的一系列处理。然而，为了执行应用程序，以下工作是必要的。

这事其实挺麻烦的。

不管怎样，要做的事情都是固定的。只需根据应用的要求进行设置。幸好Tomcat是用Java编写的。”哎呀，反正可以将Tomcat当作应用程序安装进去就好了” 这就是Spring Boot的崛起。

随着Spring Boot的问世，工作将被重新整理如下。

感觉非常清爽舒适。

API程序的修改

好吧，现在Spring Boot终于诞生了，让我们来修改程序试试看。

我想还200块钱。

现在了解了Spring Boot的概述，让我们来看一下前面创建的API Server Stub。我相信你已经注意到了，这个程序有一些问题。让我们在确认问题的同时寻找改进的方案。

首先，像上一次那样，启动应用程序。

>mvn spring-boot:run

这有点难看。这次我们将在这里更改程序，以返回200。

需要修改的部分

这次处理的资源可以大致分为三个部分。

首先io.swagger.api.SampleApi.java

...
    @RequestMapping(value = "/sample",
        method = RequestMethod.GET)
    ResponseEntity<Void> sampleGet();
...

当以GET方法调用/sample时，设置调用sampleGet()。

请查看实际的实现文件io.swagger.api.SampleApiController.java。

...
    public ResponseEntity<Void> sampleGet() {
        String accept = request.getHeader("Accept");
        return new ResponseEntity<Void>(HttpStatus.NOT_IMPLEMENTED);
        //注目　HttpStatus.NOT_IMPLEMENTED は 501を返却しています。
    }
...

如预期，sampleGet()方法已经存在。

修改内容

如果在sampleGet()函数中无论发生什么情况，都会返回NOT_IMPLEMENTED=501。现在只需要将其改为返回200即可。具体做法是

    public ResponseEntity<Void> sampleGet() {
        String accept = request.getHeader("Accept");
        //return new ResponseEntity<Void>(HttpStatus.NOT_IMPLEMENTED);
        return new ResponseEntity<Void>(HttpStatus.OK);
    }

我們會進行如下更改。

确认动作

让我们进行一下操作确认吧。
先暂停SpringBoot运行，

>mvn clean spring-boot:run

现在返回了200。

辛苦了。比如说，通过将数据访问改为DB访问，您就可以自由开发API啦。

记录作业

将创建的内容注册到git仓库中。

cd c:\dev\workspace
git add spring-server/src
git commit -m "api 修正してみたよ"
git push ★githubへ登録

总结

• JavaEE 重すぎて嫌われていたよ

• Spring FrameworkはTomcat上で実現できることを考え抜いて整理しているよ

• Spring BootはTomcatも含めてパッケージングして、実行可能なので、可搬性に優れているよ

Spring Bootのプログラムについて、HTTPリクエストに関する処理を書き換える方法がわかったよ

辛苦了。

免责声明

这份资料是为了进行此项工作而创建的，对于因此工作而导致的任何损失，我不承担任何责任。

＜＜之前的文章　菜单　下一篇文章＞＞