영원히 남는 기록, 재밌게 쓰자

[프로젝트] API 설계 시 DELETE request의 요청과 응답처리에 관한 생각 본문

프로젝트

[프로젝트] API 설계 시 DELETE request의 요청과 응답처리에 관한 생각

youngjae-kim 2024. 7. 2. 14:53
728x90
반응형

RESTful API 설계 프로젝트를 진행하던 중 학급의 학생 목록에서 학생을 삭제하는 기능과 학생 관리 페이지에서 학생을 삭제하는 요청을 처리하는 API 설계를 해야했다. 

 

나는 생성과 똑같이 POST처럼 요청 body에 삭제 요청 시 전달할 파라미터들을 담아서 요청해야겠다고 생각했는데 계속 오류가 발생하여 찾아보게 되니 DELETE 매핑은 POST와 PATCH 요청과는 조금 다른 구조를 가지고 있다는 것을 알 수 있었다.

 

생성이나 수정 시에는 보통 생성하거나 수정할 내용에 대한 요청을 요청 body에 담아서 전송한 다음 처리를 한다.

하지만 DELETE 메서드의 경우 request에 body를 포함시키는 것이 금지 되어있지는 않지만 요청 body가 포함되면 요청을 거절해버리는 경우가 있다고 한다.

나도 Axios를 사용하고 있었는데 delete요청에 body를 포함시키니 지원하지 않는 형식이라고 오류를 띄우는 것을 확인하였다.

 

또한 DELETE 요청의 경우는 데이터를 변경 시키는 행위이므로 이를 할 떄는 클라이언트의 인가 정보를 확인하여 처리하도록 이전에 구현해 놓은 Spring Security의 JWT 정보를 가지고 헤더에 포함 시켰고 요청 데이터는 쿼리 파라미터로 넘겨주었다.

 

학급 목록에서 학생 삭제 API 요청

deleteStudent(student) {
  if (confirm(student.name + '학생을 학급에서 삭제할까요?')) {
    /**
     * 리로드 하는 것이 아니라 우선 프론트쪽 데이터만 지워서 보여주기
     * 새로 고침을 하면 어차피 페이지 로드할 때 반영 된다.
     */
    axios.delete(`/api/enrollment`, {
      headers: {'Authorization': `Bearer ${localStorage.getItem('Authorization')}`},
      params: {
        studentId: student.studentId,
        classroomId: this.classInfo.classroomId,
      }
    }).then((response) => {
      if (response.status == 200) {
        alert(response.data);
      } else if (response.status == 204) {
        alert(response.data);
      }
    }).catch((err) => {
      if (err.response.status == 401) {
        alert(err.response.data);
      }
    });

    this.enrolledStudents = this.enrolledStudents.filter(s => s.id !== student.id);

  } else {
    // 취소 시 아무 로직 실행 x
  }
}

 

 

그리고 굳이 DELETE 메서드를 고집할 필요가 없다면, request body에 정보를 담고, POST 요청을 보내는 것도 다른 대안이 될 수 있다고 한다. 하지만 연습 프로젝트이다 보니 그냥 DELETE 요청 메서드도 한번 경험을 해보기 위해 DELETE 메서드를 사용하여 구현하였다.

 

클라이언트 요청이 유효한 요청이라면 서버에서 요청한 자원에 대해서 Hard Delete / Soft Delete 를 선택해야 한다.

Hard delete

  • 쿼리를 날릴 때 이전에 'Delete' 처리한 레코드를 신경쓸 필요가 없습니다.
  • 데이터베이스 용량이 상대적으로 절약됩니다.
  • 한번 삭제하면 데이터를 복구하기 힘듭니다.

Soft delete

  • 쿼리를 날릴 때 이전에 'Delete' 처리한 레코드도 신경써줘야 합니다.
  • 개인정보와 관련된 레코드를 soft delete 처리한다면 개인정보 보호법을 준수해야 합니다.
  • 데이터를 복구하거나 다른 용도로 활용할 때 간편합니다.

나의 경우는 Spring Data JPA의 delete를 사용하여 Hard Delete를 해주었다. 학생 데이터나 학급에 학생을 등록하는 경우에 이 내역들이 모두 DB에 쌓이는 것이 DB 관리 입장에서 번거로운 상황들이 더 많다고 생각하였기 떄문이다. (조회 시 삭제된 데이터를 조회하지 않는 필터링 등등)

 

응답의 경우는

  • 200 (OK): 정상 처리되어 작업에 대한 내용을 반환할 때에 '삭제 성공'이라는 메시지를 주었다.
  • 204 (NO_CONTENT): 작업은 수행되었지만 처리가 잘 안되어서 내용을 반환할게 없을 떄 해당 요청으로 처리하였다.
  • 401 (UNAHUORIZED): 헤더의 토큰 정보가 유효하지 않으면 해당 오류 메시지와 상태 코드를 반환하였다.
728x90
반응형