[일정 관리 앱] 리팩토링(4)

 이번에는 '일정' 에 해당하는 CRUD 에 해당하는 로직들을 리팩토링 해보려 한다. '도전 기능' 요구사항을 반영하였기에 '일정' 에 '날씨' 필드가 추가해야 하고, 필터에서 인증/인가가 수행되므로 더 이상 요청시 쿼리 파라미터로 작성자(회원)의 'id' 값을 전달 받을 필요가 없어졌다. 이번 리팩토링으로 수정된 코드는 여기서 확인이 가능하다.

 

참고로 일정에 관련된 모든 요청은 '인증' 이 필요하고, '일정 수정, 삭제' 요청의 경우 '인가' 가 필요하다. 요구사항에 "일정의 수정 및 삭제의 경우 관리자 권한이 필요합니다" 라는 내용이 명시되어 있기 때문이다.

 

1. 일정 생성

 일정 생성시 더 이상 쿼리 파라미터로 작성자의 정보(id)를 전달 받을 필요가 없다. 필터에서 '인증/인가' 를 수행후 요청 사용자의 정보를 DB 에서 조회해 HttpServletRequest 에 담아 전달해주기 때문에 Controller 에서 사용자 정보를 꺼내 Service 에 전달해주기만 하면 된다. 또한 날씨 정보를 제공하는 외부 저장소(Open API)를 활용하기에 Open API 에 필요 데이터를 요청(GET)하고 전달 받은 데이터 중 필요한 데이터(오늘 날씨)를 Schedule 엔티티에 저장한다.

일정 생성 요청

 

 

2. 일정 조회 및 일정 목록 조회

 일정 조회(단건, 목록)의 경우 요청 헤더에 Access Token 을 담는 것 외에는 변경된 것이 없다. 예외의 경우 인증/인가에 대한 예외가 추가되지만 이는 필터 예외를 처리하는 'ExceptionHandleFilter' 에서 핸들링하기에 추가적으로 예외를 핸들링할 핸들러를 추가할 필요가 없었다.

 

 

3. 일정 수정 및 삭제

 앞서 언급한대로 일정의 수정/삭제는 관리자(ADMIN) 권한을 가진 회원(=관리자 계정)인 경우에만 요청이 수행되어야 한다.

 

3-1. USER(일반 회원) 권한으로 요청

 이전에 관리자 계정을 직접 DB 에 아래와 같이 추가해 두었고 테스트를 위해 일반 회원 또한 MEMBER 테이블에 추가해 두었다. 요구사항이 제대로 반영이 되었다면 일반 회원이 수정 또는 삭제를 요청하면 요청이 수행되지 않아야 하고, 관리자 계정으로 요청할 경우 요청(정상 요청일 때)이 제대로 수행되어야 한다. 아래는 현재 MEMBER 테이블의 상태이다.

현재 MEMBER 테이블

 

회원의 권한이 'USER(일반 회원)' 인 회원(개발자1)과 'ADMIN(관리자)' 인 회원(관리자)가 존재한다. 먼저 '개발자1' 로 로그인해 얻은 AccessToken 으로 일정의 수정과 삭제를 요청한 결과는 아래와 같다.

일정 수정 요청 - USER 권한

일정 삭제 요청 - USER 권한

 

두 요청 모두 요청에 대한 권한을 가지지 못했다는 예외 코드 및 메시지와 '403 Forbidden' 응답을 반환한다. 필터에 적용한 인가에 대한 부분이 잘 적용된 것 같다.

 

3-2. ADMIN(관리자) 권한으로 요청

 그러면 이제 AMDIN 권한을 가진 관리자 계정을 로그인하고 발급받은 Access Token 으로 일정의 수정과 삭제를 요청해보자. 요청 수행전 SCHEDULE 테이블 상태는 아래와 같다.

일정 수정 전 SCHEDULE 테이블

 

이 상태에서 관리자 계정의 Access Token 을 헤더에 담아, 일정 수정 요청을 보내면

일정 수정 요청 - 권한 ADMIN

 

요청이 잘 수행되었다는 결과를 확인할 수 있었다. 그리고 DB 를 확인해보면

일정 수정 후 SCHEDULE 테이블

 

수정 내용이 해당 일정에 잘 반영된 것을 확인할 수 있다. 또한 수정일(update_at) 또한 수정할 때의 날짜/시간으로 수정되었다.

 

이어서 일정 삭제 요청도 확인해 보면

일정 삭제 요청 - ADMIN 권한

 

해당 요청도 잘 수행되는 것을 확인할 수 있다. 마찬가지로 DB 를 확인해 보면

일정 삭제 후 SCHEDULE 테이블

 

기존에 존재하던 일정이 잘 삭제된 것을 확인할 수 있었다.