【九月打卡】第2天 RestFul风格接口设计

一、课程介绍

【课程名称】SpringBoot 2.x 实战仿B站高性能后端项目。

【章节】第三章3.1、3.2、3.3

【讲师】HELLOSTAR

二、课程内容

**基础概念**

1.网络上的所有事物都被抽象为资源。

2.每个资源都有一个唯一的资源标识符。

3.同一个资源具有多种表现形式(xml,json等)。

4.对资源的各种操作不会改变资源标识符。

5.所有的操作都是无状态的。

**请求方式**

get 获取指定资源。

delete 删除指定资源。

post 发送数据给服务器。比如发布消息、新增用户、提交表单。

put 使用请求中的负载创建或者修改指定资源。

get、delete、put是幂等，post不是幂等。

post不具备幂等性，post指向的资源不是要创建的资源本身，而是post创建资源的接收者。

会发送两次相同的post请求。

**接口命名**

原则一：HTTP方法后跟的URL必须是名词且是复数形式
原则二：URL不采用驼峰命名法，而是全部小写，不同单词之间用“-”隔开。
比如：
/users
/users-fans
反例：
/getUsers
/getUserFans

但是命名规则知识一个约定，不是强制性规定。其实我就喜欢用反例做路径。。。

**具体使用**

在类上使用@RestController注解说明此类是restful接口风格类。

@PathVariable：接收请求路径中占位符的值

@RequestParam：请求参数，把请求中的指定名称的参数传递给控制器中的形参赋值 。

@RequestBody：请求体。主要接收前端传递给后端的请求中所有的数据，可以是集合或者任何参数。

示例代码

@GetMapping("/objects/{id}")

public Map<String, Object> getData(@PathVariable Integer id){

    return dataMap.get(id);

}



@DeleteMapping("/objects/{id}")

public String deleteData(@PathVariable Integer id){

    dataMap.remove(id);

    return "delete success";

}



@PostMapping("/objects")

public String postData(@RequestBody Map<String, Object> data){

    Integer[] idArray = dataMap.keySet().toArray(new Integer[0]);

    Arrays.sort(idArray);

    int nextId = idArray[idArray.length - 1] + 1;

    dataMap.put(nextId, data);

    return "post success";

}



@PutMapping("/objects")

public String putData(@RequestBody Map<String, Object> data){

    Integer id = Integer.valueOf(String.valueOf(data.get("id")));

    Map<String, Object> containedData = dataMap.get(id);

    if(containedData == null){

        Integer[] idArray = dataMap.keySet().toArray(new Integer[0]);

        Arrays.sort(idArray);

        int nextId = idArray[idArray.length - 1] + 1;

        dataMap.put(nextId, data);

    }else{

        dataMap.put(id, data);

    }

    return "put success";

}

三、课程收获

看完这三节RestFul风格接口的课程之后我对于开发接口的设计和命名更加熟悉了，虽然实际开发中接口的命名和请求

方式，在不强制要求的情况下我们并不会太计较如何命名和使用哪种请求方式，但是这实际上是对自己的一个要求，

我觉得不仅是在接口的设计，包括日常开发中自己写业务逻辑代码，代码内容注释，方法注释等等，让自己养成一个

良好的开发习惯，不仅对自己来说历史的代码阅读体验比较好，也能方便其他团队成员更快读懂你的代码。

四、学习过程