requisitos de aprendizaje
Buena base java, familiarizado con el marco SpringBoot, familiarizado con el marco SpringMVC
objetivos de enseñanza
Dominar el diseño de interfaz RESTful
videotutorial
5 horas para llevarlo desde que comienza a dominar el diseño de interfaz RESTful
lecho
Permítanme explicar primero que este tutorial no es académico y no se enfoca en la investigación y discusión teóricas, sino que solo enseña desde una perspectiva práctica. Antes de hablar de RESTful, hagamos tres presagios: 1> API 2> Historia del desarrollo WEB 3> Separación de front-end y back-end
¿Qué es una API?
API (interfaz de programación de aplicaciones, interfaz de programación de aplicaciones ) son algunas funciones predefinidas , o se refiere al acuerdo de diferentes componentes del sistema de software. [1] El propósito es proporcionar a las aplicaciones y a los desarrolladores la capacidad de acceder a un conjunto de rutinas basadas en una pieza de software o hardware sin tener que acceder al código fuente o comprender los detalles del funcionamiento interno .
El desarrollador A ha desarrollado el software A y el desarrollador B está desarrollando el software B.
Un día, el desarrollador B quiere usar algunas funciones del software A, pero no quiere pasar por el código fuente y el proceso de realización de funciones del software A desde el principio, ¿qué debe hacer?
El desarrollador A pensó en una buena idea: empaqueté las funciones que necesita en el software A; si coloca este paquete en el software B, ¡puede usar mi método directamente!
Entre ellos, API es el método que dijo el desarrollador A.
Etapas del desarrollo web.
El desarrollo de la tecnología de desarrollo web se puede dividir aproximadamente en las siguientes etapas
Fase de contenido estático : en esta fase inicial, la Web es utilizada principalmente por instituciones de investigación. La Web consta de un gran número de documentos HTML estáticos.
Fase del programa CGI : en esta fase, el servidor web agrega algunas API de programación. Las aplicaciones escritas a través de estas API pueden proporcionar contenido que cambia dinámicamente a los clientes. .
Etapa de lenguaje de secuencias de comandos : en esta etapa, las tecnologías de lenguaje de secuencias de comandos que admiten sesiones, como ASP, PHP, JSP y ColdFusion, aparecen en el lado del servidor, y tecnologías como Java Applet y JavaScript aparecen en el lado del navegador. Usando estas técnicas, se puede proporcionar un contenido más rico y dinámico.
Etapa de aplicación de cliente ligero : en esta etapa, aparece en el lado del servidor un servidor de aplicaciones independiente del servidor web. Al mismo tiempo, apareció el modelo de desarrollo Web MVC y varios marcos de desarrollo Web MVC se hicieron gradualmente populares y ocuparon una posición dominante. Las aplicaciones web desarrolladas en base a estos marcos suelen ser aplicaciones de cliente ligero porque generan todo el contenido dinámico en el lado del servidor.
Etapa de aplicación RIA : en esta etapa, surgieron una variedad de tecnologías RIA (Rich Internet Application), que mejoraron en gran medida la experiencia del usuario de las aplicaciones web. La tecnología RIA más utilizada es DHTML+Ajax. La tecnología Ajax admite la actualización dinámica de contenido parcial en una página sin actualizar la página. Al mismo tiempo, nació una gran cantidad de bibliotecas de desarrollo DHTML front-end web, como Prototype, Dojo, ExtJS, jQuery/jQuery UI, etc.
Etapa de aplicaciones web móviles : en esta etapa han surgido una gran cantidad de tecnologías de desarrollo de aplicaciones web para dispositivos móviles. Además de las tecnologías de desarrollo nativas de plataformas de sistemas operativos como Android, iOS y Windows Phone, las tecnologías de desarrollo basadas en HTML5 también se han vuelto muy populares.
Separación tradicional VS front-end y back-end
modelo de desarrollo tradicional
El front-end escribe la página html estática en el desarrollo de back-end, el back-end cambia el html en una plantilla y luego usa el motor de plantillas para configurar la plantilla, como jsp, freemarker y otro personal de back-end. Si hay un problema con la página durante el proceso de desarrollo, debe devolverse. El front-end se modifica y el front-end se entrega al back-end hasta que se realice la función.
Problema: Extremos delantero y trasero severamente acoplados
1. Cuando el front-end necesita modificar errores y depurar, es necesario instalar un conjunto completo de herramientas de desarrollo de back-end en la computadora actual e iniciar el programa de back-end.
2. También se requiere que el personal de back-end conozca lenguajes de front-end como html y js.
3. La página de inicio también incrustará una gran cantidad de código de back-end
4. Una vez que el backend se cambia a un idioma, también se debe volver a desarrollar el frontend
5. Los costos de comunicación, los costos de depuración, el progreso del desarrollo de front-end y back-end se afectan entre sí, lo que reduce en gran medida la eficiencia del desarrollo.
Separación de los extremos delantero y trasero.
La separación de front-end y back-end no es solo un modo de desarrollo, sino también un modo arquitectónico de aplicaciones web. En la etapa de desarrollo, el personal de front-end y back-end acuerda la interfaz de interacción de datos y luego pueden desarrollar y probar en paralelo.
Una vez que se completa el desarrollo del front-end, las pruebas simuladas se pueden realizar de forma independiente, y el back-end también se puede probar utilizando herramientas de prueba de interfaz como postman. Finalmente, se puede llevar a cabo la prueba de depuración conjunta de funciones.
ventaja:
1. Las responsabilidades de front-end y back-end son claras, el back-end se enfoca en los datos y el front-end se enfoca en la visión.
2. No hay necesidad de esperar hasta el final del trabajo de desarrollo de la otra parte para mejorar la eficiencia del desarrollo.
3. Puede hacer frente a requisitos front-end complejos y cambiantes.
4. Mejorar la capacidad de mantenimiento del código
Diseño de interfaz RESTful
razón de la existencia
Con la aparición de la etapa web 2.0, el cliente no se limitará a los navegadores de PC, puede ser una aplicación móvil o un pequeño programa, que requiere que el servidor proporcione una interfaz API unificada, y diferentes tipos de clientes se basan en el mismo protocolo/Reglas puede llamar a la interfaz API y obtener los datos esperados.
En este punto, el núcleo: ¿cómo diseñar un conjunto de interfaz API científica?
Diferentes desarrolladores tienen diferentes hábitos de diseño para las interfaces API, por ejemplo, esto puede suceder
新增员工:
http://localhost/employee/save
http://localhost/employee/add
http://localhost/employee/new
http://localhost/employee/xinzeng
http://localhost/employee/append
http://localhost/employee?cmd=add
而且发送的请求方式以及响应结果也比较可能随意 Respuesta: interfaz API con estilo RESTful
estilo REPOSO
REST es una regla (estilo) para el diseño de interfaces API, muy popular en proyectos web debido a su simplicidad, legibilidad y facilidad de uso. Al diseñar una interfaz, una aplicación o diseño que satisface las restricciones y los principios de REST se denomina aplicación RESTful.
reglas vinculantes
Mirando hacia atrás, el diseño de la interfaz web tradicional (método de asignación de solicitudes) debe considerar varios puntos.
Tome la lista de empleados como ejemplo.
@Controller
public class EmployeeController {
@RequestMapping("/employee/list")
public String list(Model model){
model.addAttribute("list", employeeService.list())
return "employee/list";
}
}diseño de interfaz tradicional
Al diseñar interfaces web tradicionales, considere:
1> Solicitar ruta
Generalmente, se adopta el método de ver el nombre y saber el significado, como: /empleado/lista
2> Método de solicitud
No importa, la anotación @RequestMapping puede aceptar cualquier método de solicitud, incluido: GET POST
3> Solicitar parámetros
No fijo, depende de la función de la interfaz, se puede decir que está determinado por la demanda
4> Solicitud de respuesta
No es fijo, depende de los requisitos, puede ser en formato Json o una plantilla de página.
Diseño de interfaz RESTful
Tome la lista de empleados como ejemplo.
@Controller
public class EmployeeController {
@RequestMapping(value = "/employees", method = RequestMethod.GET)
@ResponseBody
public List<Employee> list(){
return employeeService.list();
}
}1> Solicitar ruta
Ya no es una forma de saber el nombre, sino que está determinado por el recurso de la operación, generalmente se utiliza la forma plural del nombre del recurso.
Por ejemplo, el objeto de operación de la interfaz (recurso) es un empleado y la ruta se puede diseñar como: /empleados
La pregunta es, ¿qué son los recursos?
todo es un recurso
A los ojos de RESTful, todo en Internet es un recurso, y cada recurso tiene un localizador de recursos único (URI).
Una imagen es un recurso: https://c-ssl.duitang.com/uploads/item/201810/17/20181017111458_dqioq.jpg
Una página web es un recurso: Baidu, lo sabrás
Una ruta de solicitud es un recurso: http://localhost:8080/employee?id=1
Volviendo al código, la url http://localhost:8080/employee?id=1 significa consultar la información del empleado con id=1 en la base de datos. Esta información del empleado es el recurso descrito en Restful. Generalmente, no solo hay un recurso, como un empleado No solo los datos con id=1, la mayoría de ellos están en plural, por lo que el acuerdo RESTful: para que la interfaz opere recursos, use plural de manera unificada.
@RequestMapping("/employees")
public class EmployeeController{
}Eche un vistazo a los siguientes ejemplos:
recurso del departamento
http://www.langfeiyes.cn/depts
recurso del zoológico
https://api.example.com/v1/zoos
recurso de animales
https://api.example.com/v1/ criador de animales
Recurso
https://api.example.com/v1/employees
Mire la interfaz relajante escrita por otros Jiguang IM - API REST - Documentación de Jiguang
El resumen vernáculo final: diseño de interfaz RESTful: el camino generalmente es operar la pluralidad de objetos de entidad
2> Método de solicitud
El método de diseño de interfaz tradicional, utilizando la ruta de diseño de conocer el nombre y el significado, puede ver el funcionamiento de la interfaz en el recurso desde la ruta, pero la interfaz de estilo RESTful utiliza la cantidad plural de recursos como ruta, por lo que es imposible para ver el funcionamiento de la interfaz en el recurso desde la ruta, entonces, ¿qué debo hacer?
El estilo RESTful hace un escándalo por el método de solicitud HTTP y está de acuerdo:
OBTENER (SELECCIONAR): Obtenga un recurso (uno o más elementos) del servidor.
POST (CREATE): Crea un nuevo recurso en el servidor.
PUT (UPDATE): Actualiza el recurso en el servidor (el cliente proporciona el recurso completo después del cambio). PUT actualiza todo el objeto
PARCHE (ACTUALIZAR): recurso de actualización en el servidor (el cliente proporciona atributos modificados [parche]). PARCHE para actualizar atributos individuales
DELETE (DELETE): Elimina un recurso del servidor.
//aprender
HEAD: Obtener los metadatos de un recurso, como el valor hash o la fecha de última modificación de un recurso; OPCIONES: Obtener las operaciones que el cliente puede realizar sobre un recurso; (obtener la api del recurso (la descripción de qué operaciones puede realizarse en el recurso))
La ruta tradicional ve el nombre y el significado = ruta RESTful + método de solicitud
ejemplo
Forma tradicional:
http://www.langfeiyes.cn/employee/list
http://www.langfeiyes.cn/employee/get?id=1
http://www.langfeiyes.cn/employee/save?name=xx
http://www.langfeiyes.cn/employee/update?id=1&name=xx
http://www.langfeiyes.cn/employee/delete?id=1
manera REPOSA:
http://www.langfeiyes.cn/employees
Agregar: POST
Actualizar: PUT
Eliminar: ELIMINAR
Consulta: GET
GET /zoos: muestra todos los zoológicos
POST /zoos: crea un nuevo zoológico
GET /zoos/{id}: obtiene la información de un zoológico específico
PUT /zoos/{id}: actualiza la información de un zoológico específico (proporciona la información de el zoológico Toda la información)
PATCH /zoos/{id}: actualiza la información de un zoológico específico (proporciona información sobre el zoológico)
DELETE /zoos/{id}: elimina un zoológico
GET /zoos/{id}/animals: lista Todos los animales en un zoológico dado
Obtener todos los empleados en un departamento
GET /employee/getByDeptId solía ser más informal
GET /departamentos/{id}/empleados descansados风格
3> Solicitar parámetros
No fijo, depende de la función de la interfaz, se puede decir que está determinado por la demanda
4> Solicitud de respuesta
RESTful
ha llegado a un acuerdo detallado sobre el valor de respuesta:
GET /colección: devuelve una lista (matriz) de objetos de recursos
GET /colección/recurso: devuelve un objeto de recurso único
POST /colección: devuelve un objeto de recurso recién generado
PUT /colección/recurso: devuelve un objeto de recurso completo
PATCH /colección/recurso : devuelve el objeto de recurso completo
ELIMINAR /colección/recurso: devuelve un documento vacío
Los retornos de datos anteriores están todos en formato Json.
El desarrollo real y los datos de respuesta específicos se basan principalmente en las regulaciones/necesidades operativas de la empresa.
Expansión relacionada
Código de estado de respuesta HTTP
200 OK - [GET]: El servidor devolvió con éxito los datos solicitados por el usuario.
201 CREADO - [POST/PUT/PATCH]: el usuario creó o modificó correctamente los datos.
202 Aceptado - [ ]: indica que una solicitud se ha puesto en cola en segundo plano (tarea asíncrona)
204 SIN CONTENIDO - [ELIMINAR]: el usuario elimina los datos correctamente.
400 SOLICITUD NO VÁLIDA - [POST/PUT/PATCH]: Hay un error en la solicitud enviada por el usuario, y el servidor no creó ni modificó datos, esta operación es idempotente.
401 No autorizado - [ ]: Indica que el usuario no tiene permiso (error de token, nombre de usuario, contraseña).
403 Prohibido: [ ] indica que el usuario está autorizado (a diferencia de un error 401), pero el acceso está prohibido.
404 NO ENCONTRADO - [ ]: La solicitud enviada por el usuario es para un registro que no existe, y el servidor no ha realizado ninguna operación, lo cual es idempotente.
406 No Aceptable - [GET]: El formato solicitado por el usuario no está disponible (por ejemplo, el usuario solicita el formato JSON, pero solo el formato XML).
410 Gone -[GET]: El recurso solicitado por el usuario se elimina de forma permanente y no se volverá a obtener.
422 Entidad no procesable: [POST/PUT/PATCH] Se produjo un error de validación al crear un objeto.
500 ERROR INTERNO DEL SERVIDOR - [*]: Ocurrió un error en el servidor y el usuario no podrá determinar si la solicitud fue exitosa.
representación de recursos
Por ejemplo, el texto se puede expresar en formato txt, formato HTML, formato XML, formato JSON o incluso formato binario; las imágenes se pueden expresar en formato JPG o PNG.
Su forma específica de expresión debe especificarse en la información del encabezado de la solicitud HTTP con los campos Aceptar y Tipo de contenido, y estos dos campos son la descripción de la "expresión".
aceptar: aplicación/json tipo de contenido: aplicación/json
La diferencia entre Aceptar y Tipo de contenido 1. Aceptar pertenece al encabezado de la solicitud y el Tipo de contenido pertenece al encabezado de la entidad. Los encabezados Http se dividen en encabezados generales, encabezados de solicitud, encabezados de respuesta y encabezados de entidad. La estructura del encabezado http del solicitante: encabezado general|encabezado de solicitud|encabezado de entidad La estructura del encabezado http del respondedor: encabezado general|encabezado de respuesta|encabezado de entidad
2.Aceptar representa el tipo de datos que el remitente (cliente) desea aceptar. Por ejemplo: Aceptar: aplicación/json; significa que el tipo de datos que el cliente quiere aceptar es tipo json, y el fondo devuelve datos json
Content-Type representa el tipo de datos de los datos de la entidad enviados por el remitente (cliente|servidor). Por ejemplo: Content-Type: application/json; significa que el formato de datos enviado por el remitente es json, y el fondo debe usar este formato para recibir los datos enviados por el front-end.
Precaución
REST es solo un estilo de diseño, no un estándar. Solo proporciona un conjunto de principios y restricciones de diseño, y la operación específica se combina con los requisitos de la empresa/requisitos del proyecto.
Marco RESTful
Los comunes son SpringMVC, jersey, play
Herramienta de prueba de API
cartero, insomnio
Práctica de interfaz RESTful
preparación del proyecto
1> Cree un proyecto Springboot estándar, utilizando el entorno web
confiar
<!-- SpringBoot的依赖配置-->
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.4.3</version>
<relativePath/>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.20</version>
<scope>provided</scope>
</dependency>
</dependencies>
2> configurar aplicación.propiedades
server.port=803> Editar clase de entidad, clase de inicio, clase de controlador
@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
public class Employee {
private Long id;
private String name;
private int age;
}
@SpringBootApplication
public class App {
public static void main(String[] args) {
SpringApplication.run(App.class, args);
}
}
@Controller
public class EmployeeController {
}diseño de interfaz
1. Obtener todos los empleados
/**
* 需求： 查询所有员工数据
* 1>请求路径: 确定资源： /employees
* 2>请求方式： GET
* 3>请求参数： 无
* 4>请求响应： List<Employee> Json格式
*/
@RequestMapping(value = "/employees", method = RequestMethod.GET)
@ResponseBody
public List<Employee> list(){
return Arrays.asList(new Employee(1L, "dafei", 18),
new Employee(2L, "xiaofei", 17) );
}prueba
URL：http://localhost:80/empleados
Método de solicitud: OBTENER
2. Agregar un empleado
/**
* 需求： 添加一个员工信息
* 1>请求路径: 确定资源： /employees
* 2>请求方式： POST
* 3>请求参数： 员工相关信息（属性）
* 4>请求响应： Employee Json格式
*/
@RequestMapping(value = "/employees", method = RequestMethod.POST)
@ResponseBody
public Employee add(Employee employee){
employee.setId(1L); //假装添加到数据，新增id为1L
return employee;
}prueba
URL：http://localhost:80/empleados
Método de solicitud: POST
Parámetros: nombre, edad
3. Actualizar los datos de los empleados
/**
* 需求： 更新一个员工信息
* 1>请求路径: 确定资源： /employees
* 2>请求方式： PUT
* 3>请求参数： 员工相关信息（属性）
* 4>请求响应： Employee Json格式
*/
@RequestMapping(value = "/employees", method = RequestMethod.PUT)
@ResponseBody
public Employee update(Employee employee){
employee.setName(employee.getName() + "_update");
return employee;
}prueba
URL：http://localhost:80/empleados
Método de solicitud: PUT
Parámetros: id, nombre, edad
4. Eliminar un empleado
Requisitos, después de que la operación sea exitosa, se devolverá el indicador de estado de la operación y se requiere un objeto de encapsulación de estado personalizado adicional (valor de retorno unificado)
@Setter
@Getter
public class JsonResult{
private int code; //状态码
private String msg;//提示信息
private Object data;//结果数据
public JsonResult(int code, String msg, Object data){
this.code = code;
this.msg = msg;
this.data = data;
}
public static JsonResult success(){
return new JsonResult(200, "操作成功", null);
}
public static JsonResult error(String msg){
return new JsonResult(500, msg, null);
}
}
/**
* 需求： 删除一个员工信息
* 1>请求路径: 确定资源： /employees
* 2>请求方式： DELETE
* 3>请求参数： id
* 4>请求响应： 状态提示(成功/失败)
*/
@RequestMapping(value = "/employees", method = RequestMethod.DELETE)
@ResponseBody
public JsonResult delete(Long id){
return JsonResult.success();
}prueba
URL：http://localhost:80/empleados
Método de solicitud: ELIMINAR
Parámetro: identificación
5. Obtener información sobre un empleado
/**
* 需求： 查询指定id的员工数据
* 1>请求路径: 确定资源： /employees
* 2>请求方式： GET
* 3>请求参数： id
* 4>请求响应： Employee Json格式
*/
@RequestMapping(value = "/employees", method = RequestMethod.GET)
@ResponseBody
public Employee detail(Long id){
return new Employee(id, "dafei", 18);
}Cuando se inicia el proyecto, se informa un error directamente, diciendo que el mapeo de mapeo se repite
Analiza las razones
/**
*
* 查询所有员工与查询某个员工， 使用路径： /employees 使用方法： GET 都相同
* 此时在springmvc语法中，2个请求是不允许共存的。此时怎么办？
*
* 方案1：使用多级路径方式区分， 比如： /employees/detail
* 方案2：参数路径的方式
* 参数路径：请求映射接口中，将请求参数作为路径的一部分
* 比如：/employees/{id} {id} 路径参数的占位符
* 注意：客户发起请求时：
url路径写法： http://localhost:8080/employees/1 其中 1 是路径参数
*
* 接口想要获取路径中参数，需要使用：@PathVariable 注解
* @PathVariable 作用：将url路径上参数解析并赋值到请求映射方法的形式参数
* 注意： 如果路径参数的占位符跟请求映射方法的形式参数名不一致，需要使用注解属性明确指定
* "/employees/{eid}" ---> @PathVariable("eid")
*
*/plano 1:
@RequestMapping(value = "/employees/detail", method = RequestMethod.GET)
@ResponseBody
public Employee detail(Long id){
return new Employee(id, "dafei", 18);
}
prueba
URL: http://localhost:80/empleados/detalle
Método de solicitud: OBTENER
Parámetro: identificación
Escenario 2:
@RequestMapping(value = "/employees/{id}", method = RequestMethod.GET)
@ResponseBody
public Employee detail(@PathVariable Long id){
return new Employee(id, "dafei", 18);
}prueba
URL: http://localhost:80/empleados/1
Método de solicitud: ELIMINAR
expansión de ruta de parámetro
interfaz de solicitud de página
Requisitos: hay 5 botones en la página, haga clic para iniciar una solicitud asíncrona y acceda a la interfaz tranquila correspondiente
1> importar jquery.js
2> Escribir página info.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
<script src="js/jquery/jquery.min.js"></script>
<script>
$(function () {
$("#btn1").click(function () {
$.get("/employees/1",function (data) {
console.log(data);
})
})
$("#btn2").click(function () {
$.get("/employees",function (data) {
console.log(data);
})
})
$("#btn3").click(function () {
$.post("/employees", {name:"dafei", age:18}, function (data) {
console.log(data);
})
})
$("#btn4").click(function () {
$.ajax({
url:"/employees",
type:"PUT",
data:{id:1, name:"dafei", age:18},
success:function (data) {
console.log(data);
}
})
})
$("#btn5").click(function () {
$.ajax({
url:"/employees",
type:"DELETE",
data:{id:1},
success:function (data) {
console.log(data);
}
})
})
})
</script>
</head>
<body>
<button id="btn1">查单个</button><br>
<button id="btn2">查所有</button><br>
<button id="btn3">添加</button><br>
<button id="btn4">更新</button><br>
<button id="btn5">删除</button><br>
</body>
</html>3 > Accede, haz clic en el botón a su vez
Aviso
SpringMVC no admite el procesamiento de solicitudes de colocación de forma predeterminada, y es necesario configurar filtros para procesar solicitudes de colocación o parches
<filter>
<filter-name>httpPutFormContentFilter</filter-name>
<filter-class>org.springframework.web.filter.HttpPutFormContentFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>httpPutFormContentFilter</filter-name>
<servlet-name>springMVC</servlet-name>
</filter-mapping>
Interfaz RESTful simplificada
@RestController
Compuesto por @Controller + @ResponseBody, pegado en la clase de controlador
@PathVariable
Los parámetros de marcador de posición en la URL se pueden vincular a los parámetros de entrada del método de procesamiento del controlador a través de @PathVariable
El marcador de posición {xxx} en la URL se puede vincular al parámetro de entrada del método de operación a través de @PathVariable ("xxx").
Pegar los parámetros del método de mapeo solicitados
@GetMapping se adjunta al método de asignación de solicitudes, que es equivalente a: @RequestMapping(method = RequestMethod.GET)
@PostMapeo
Pegado en el método de asignación de solicitudes, equivalente a: @RequestMapping(method = RequestMethod.POST)
@PutMapping
Pegue el método de asignación de solicitudes, equivalente a: @RequestMapping(method = RequestMethod.PUT)
@DeleteMapping
Pegue el método de asignación de solicitudes, equivalente a: @RequestMapping(method = RequestMethod.DELETE)
@RestController //等价于：@ResponseBody + @Controller
@RequestMapping("employees")
public class EmployeeController {
@GetMapping
public List<Employee> list(){
return Arrays.asList(new Employee(1L, "dafei", 18),
new Employee(2L, "xiaofei", 17) );
}
@GetMapping("/{id}")
public Employee detail(@PathVariable Long id){
return new Employee(id, "dafei", 18);
}
@PostMapping
public Employee add(Employee employee){
employee.setId(1L);
return employee;
}
@PutMapping
public Employee update(Employee employee){
employee.setName(employee.getName() + "_update");
return employee;
}
@DeleteMapping
public JsonResult delete(Long id){
return JsonResult.success();
}
}
Atributo de anotación RequestMapping
valor/ruta : ruta de mapeo; método : forma de limitar la solicitud, enumeración:
public enum RequestMethod {
GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE
}params : limite los parámetros que se procesarán en la solicitud, solo las solicitudes que coincidan con los parámetros serán procesadas por este método;
/**
* @RequestMapping(value = "/test", params = {"name"}) 要求请求必须带上name参数
* @RequestMapping(value = "/test", params = {"name=dafei"}) 要求请求必须带上name参数，并且值为dafei
*/
@RequestMapping(value = "/test", params = {"name=dafei"})
@ResponseBody
public String test(){
} encabezados : limite la información del encabezado de la solicitud que se procesará. Solo las solicitudes que coincidan con el contenido del encabezado de la solicitud serán procesadas por este método;
@RequestMapping(value = "/test2", headers = {"accept=application/json"})
@ResponseBody
public String test2(){
return "ok--json";
}
@RequestMapping(value = "/test2", headers = {"content-type=application/xml"})
@ResponseBody
public String test3(){
return "ok--xml";
}consume : limite la información del encabezado de la solicitud que se procesará y especifique claramente el tipo de parámetros que lleva el cliente
//等价于：@RequestMapping(value = "/test2", headers = {"content-type=application/json"})
@RequestMapping(value = "/test2", consumes = {"application/json"})
@ResponseBody
public String test4(){
return "ok--json";
}produce : limite la información del encabezado de la solicitud que se procesará y especifique claramente que el cliente espera que el servidor responda con el tipo de parámetro especificado
//等价于：@RequestMapping(value = "/test2", headers = {"accept=application/json"})
@RequestMapping(value = "/test2", produces = {"application/json"})
@ResponseBody
public String test5(){
return "ok--json";
}Resumir
El diseño de interfaz RESTful es tal cosa
1> Solicitar ruta
Determine el recurso de operación específico y combine los requisitos, puede agregar el prefijo y el sufijo de la ruta de manera adecuada, o usar el método de ruta de parámetro
2> Método de solicitud
De acuerdo con la función real de la interfaz, encuentre el método apropiado para el CRUD de recursos
Recursos desde cero: POST
Recurso de existencia a no existencia: ELIMINAR
Recurso del estado A al estado B: PUT
Estado del recurso sin cambios: GET
3> Solicitar parámetros
Según la función de la interfaz, los parámetros se pasan bajo demanda
4> Solicitud de respuesta
De acuerdo con la implementación de la interfaz y los requisitos de llamada del cliente, se determina el valor de retorno específico. Se recomienda utilizar el formato JSON.
Para resumir una oración: RESTful es un estilo de diseño de interfaz. Se recomienda que lo cumpla. Durante el desarrollo, debe manejarse de manera flexible en combinación con la situación real bajo la premisa de cumplimiento.
Tarea
Consultar a todos los empleados de un determinado departamento
/departamentos/{id}/empleados
Consultar la colección de todos los salarios de los empleados
/empleados/salarios
Consultar el salario de un empleado para un mes determinado
/empleados/{id}/salarios/{mes}
Operación de inicio de sesión de usuario
/usuarios/iniciar sesión --POST
Operación de cierre de sesión de usuario
/usuarios/cerrar sesión --ELIMINAR
Buscar por nombre de usuario
/usuarios/{nombre}
Buscar por edad
/usuarios/{edad}