今天做了什么

按照网上教程整合spring+springmvc+mybaits,

但失败了，就不贴代码了，准备明天重新做

报错如下

文件目录如下

但是对于ssm运转流程结合springmvc，理解的更透彻了一些

MVC 是一种使用 MVC（Model View Controller 模型-视图-控制器）设计创建 Web 应用程序的模式： 

Model（模型）表示应用程序核心（比如数据库记录列表）。

View（视图）显示数据（数据库记录）。

Controller（控制器）处理输入（写入数据库记录）。

MVC 模式同时提供了对 HTML、CSS 和 JavaScript 的完全控制。

Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。

　　通常模型对象负责在数据库中存取数据。

View（视图）是应用程序中处理数据显示的部分。

　　通常视图是依据模型数据创建的。

Controller（控制器）是应用程序中处理用户交互的部分。

　　通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

MVC 分层有助于管理复杂的应用程序，因为您可以在一个时间内专门关注一个方面。例如，您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。

MVC 分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。

一般来说 ，springmvc负责Controller层，mybaits负责model层里的orm映射（dao和mapper ，sql语句），spring通过IOC和AOP负责将其连接起来，并且其本身并不是和springmvc,mybaits隔离开的。

HTTP请求方式

GET ( SELECT ) ：从服务器取出资源（一项或多项）。

POST ( CREATE )：在服务器新建一个资源。

PUT ( UPDATE ）：在服务器更新资源（客户端提供改变后的完整资源）。

PATCH ( UPDATE ) : 在服务器更新资源（客户端提供改变的属性）。

DELETE  ( DELETE ) : 从服务器删除资源。

HEAD：获取资源的元数据。

OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

过滤信息（Filtering）

如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤后返回结果。

下面是一些常见的参数。

？limit=10：指定返回记录的数量

？offset=10：指定返回记录的开始位置。

？page=2&per_page=100：指定第几页，以及每页的记录数。

？sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。

？animal_type_id=1：执行筛选条件。

参数的设计允许存在冗余，即允许API路径和URL参数偶尔有重复。比如，GET/zoo/ID/animals与GET/animals？zoo_id=ID的含义是相同的。

状态码（Status Codes）

服务器向用户返回的状态码和提示信息，常见的有以下一些（方括号中是该状态码对应的HTTP动词）。

• 200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。
• 201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。
• 202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）
• 204 NO CONTENT - [DELETE]：用户删除数据成功。
• 400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。
• 401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。
• 403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。
• 404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。
• 406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
• 410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
• 422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。
• 500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。

错误处理（Error handling）

如果状态码是4xx，就应该向用户返回出错信息。一般来说，返回的信息中将error作为键名，出错信息作为键值即可。

{ error：“Invalid API key”}

基于restful设计任务二的api：

根据接口文档规范开发接口

概述：文档不是给自己看的，只有自己才看得懂的文档就不要放上去浪费其他同学的时间了。

所有文档至少包含以下信息：

1.接口功能

2.接口路径

3.接口入

4.接口出

5.各字段说明、约定值、是否必填、默认参

6.复杂数据结构给出出范例

1）新增学生信息：POST /Task2/student

请求参数：

返回参数：

2）查询学生信息：GET /Task2/student/{id}

请求参数

返回参数：

data：

3）修改学生信息：PUT /Task2/student/{id}/{slogan}

请求参数

返回参数

4）删除学生信息：DELETE /Task2/student/{id}

请求参数

返回参数

总结：

1.做了SSM的整合，但是虽然失败了，但是加深了对SSM框架的理解，另外感觉自己过于着急了，应该适当放慢，一步一步来

2.了解了下http请求，结合restfuil规范和其他参考，写出了接口规范，（可能有错，后续要修改）

踩坑：

在使用jetty服务器时，

使用maven配置后，利用idea，跑maven的jetty插件跑不起来

必须使用命令行才可以，第一次运行会下载相关依赖

明天要做什么

按照任务二要求一步一步来

根据接口文档，使用Spring Rest 编写对应的Controller，日志记录接收参数后，暂时不用写业务逻辑，直接返回JSP，直接用Json Tag-lib 生成假数据

本地运行Jetty：run 插件，修改端口号为8080，浏览器访问任意查询接口，判断是否可以正确返回数据

用Postman或者dhc测试接口文档，返回数据是否成功