Spring boot的基础总结(一)-------Spring MVC,RESTful APi

本文根据Spring boot去建立一个简易的开发环境，用作于json数据的交互。

那一个简易的后端功能需要具备什么功能？

1.最重要的当然是能运行啦

这里就不纠结如何配置环境和跑了，只要记得maven是用来配置包，新建项目然后主程序入口在包的最上级进行跑就好了。

2.代码容易看，易解耦，风格统一

在这里，我们需要了解Spring MVC,RESTful API .
ok,从之后开始我们就要接触到Spring boot MVC的东西了。其实可以算是一种编程思想，或者流程思想，网上总是说它是什么东西，其实本人更想知道的是为什么它是这样的，为什么这样设计。
M层:model层，模型层，可以说是作为中间层。
C层：控制层，就是用户发起的请求。到的Control.
V层:View层，前端的Html。

从用户开始请求C层，再到M层处理数据，最后V层返回给用户呈现的整个步骤，其实Spring boot已经全部集成做好了，并没有要求我们开发者去了解这中间到底发生了什么。这让我们省下了很多去将这里文件链接起来。
而且分层也自然而然的让开发者文件的分布变得更加合理，让你的代码不会全部堆在一个文件中

但是Spring boot现在网上教程存在另一个问题, 一般来讲，已经前后端分离了，往往很多时候V层不需要我们考虑，我们只需要专注于业务数据的开发即可。
那为了代码可复用，可扩展，不杂乱，我们常常将C，M层拆成3个模块.

Control:专注用户进入入口，和简单的逻辑判断，控制返回。
Server:专注于对数据的处理，设置和操作。
dao:对数据库进行数据请求并返回Server.

其实这么看，其实也很像一个小型的MVC结构。
问题来了，目的是什么呢？
分层！解耦！复用！代码不乱！知道错了去到哪里改！不至于一个文件上万行！
只要稍微我们试想一下，如果在Control层里面，即接收，又设置数据，又请求，你就知道一个入口函数就有多大了。
随便举个栗子：

单纯的String，还没搭上数据库的查询，就20行了，更别说复杂的实体类了。所以，分层是十分重要且有必要的!

上面说的都是项目结构上的一些细节，下面则需要了解RESTful风格的API，先说结论好了。
为了让API也具有编程语义的功能不知道各位有没有遇到过代码什么，a= 0, b= 0, c=0,然后用到业务里面去啊，如果这样用的话，可能领导要你看代码的时候，你可能得想死一死，因为很有可能你根本看不懂人家在写什么东西。

为了让开发者一看就知道这个API具有什么功能，约束Web中的功能而已。
简单举个栗子:
都是获取动物园信息的接口
非RESTful:localhost/ZoomMessage/Task
RESTful:localhost/Get/Zoom/Message

虽然栗子不是很好，但是我们能看出区别的就是，非RESTful风格的接口，没办法直接告诉我们这个API到底是干嘛，只能去接口文档去找。如果接口文档更新的很慢，文档不对劲呢？那在沟通中又要浪费很多时间，开发的很痛苦。
RESTful赋予了接口语义，看APi就知道Api的功能是啥了，当然这样容易让别人猜到你的API接口，对安全有要求，这些之后再谈。这里有一个重点就是要知道，RESTful接口的路径需要接近名词，可以说唯一的动词就是GET,POST,DELECT等。

RESTful API风格说明：
RESTful API主要是规定路径的最终命名，表示API的具体网址。
在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的"集合"（collection），所以API中的名词也应该使用复数。
举例来说，有一个API提供动物园（zoo）的信息，还包括各种动物和雇员的信息，则它的路径应该设计成下面这样，当然还有一些建议带版本号会在路径里面带上，但是版本号我们在json数据内的.
 https://api.example.com/zoos
 https://api.example.com/animals
 https://api.example.com/employees

对于资源的具体操作类型，由HTTP动词表示。
常用的HTTP动词有下面五个（括号里是对应的SQL命令）。
 GET（SELECT）：从服务器取出资源（一项或多项）。
 POST（CREATE）：在服务器新建一个资源。
 PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
 PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
 DELETE（DELETE）：从服务器删除资源。
下面是一些例子。
 GET /zoos：列出所有动物园
 POST /zoos：新建一个动物园
 GET /zoos/ID：获取某个指定动物园的信息
 PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
 PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）
 DELETE /zoos/ID：删除某个动物园
 GET /zoos/ID/animals：列出某个指定动物园的所有动物
 DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

了解更多

当然了，结构，架构，分层，风格，这种都不是任何的硬性风格，而且我相信也有更好的方式去解决，但是我们更需要去理解的是这些风格带来的好处是什么，以及为什么这种风格可以带来这种好处，这更值得我们去思考。