성공 응답이 다양할 필요가 있을까

2022년 07월 06일

하나의 api요청에서 Exception은 몇가지, 또는 몇십가지까지도 생길 수 있다
그렇기에, 빠른 Exception의 처리를 위해서 실패 응답에는
가능한 모든 Exception의 이유가 기술되어 있어야 한다고 생각한다.

하지만 api의 성공 응답은 거의 하나(1:1 관계)이기 때문에,
굳이 다양한 성공 응답을 할 필요가 없다 (시간 자원이 낭비됨)

특별히 이메일 인증의 성공 응답은, 하나의 api에서 두 개의 성공 응답을 주기 때문에 살아남았다
RIP. SuccessResponses...

⬇

S3 서버와 Files 테이블

2022년 07월 07일

게시판 CRUD 기능들을 구현한 후 게시판 생성은 잘 작동하는데,
게시판 삭제 기능에서 게시판에 포함된 파일들이 S3 서버에서 지워지지 않는것을 확인했다

삭제하는 메서드의 파라미터로 url값을 사용하고 있었는데,
S3 파일의 삭제에 사용하는 DeleteObjectRequest 클래스의 파라미터를 확인 해 보니,
bucketName과 key라는 변수명의 파라미터를 받았다. 변수명이 fileUrl이 아닌 key인 것에 힌트를 얻어
S3 파일의 생성에 쓰였던 PutObjectRequest에서의 key가 그대로 쓰인다는 것을 알았다
key는 (UUID와 OriginalFilename을 합친) fileName을 사용하였다

Files 테이블에선 url만을 컴럼으로 가지고 있었고, S3Service와 GoodsService에서도
url(bucketName + ".s3." + region +".amazonaws.com/" + fileName)만을 사용하였기에, url내에 있는 fileName과 bucketName, region을 따로 다룰 수 있게 테이블을 수정하기로 하였다

S3Service에서의 return값 `url` => bucketName + ".s3." + region +".amazonaws.com/" + fileName

GoodsService에서 goods객체와 fileUrl만을 Files테이블에 저장했다

수정 전 Files 테이블

해결

해당 url을 분석하여 fileName만을 뽑아내도 되지만,
S3Service에서 값을 나눠서 Map 타입으로 주는 방식을 택했다

변경한 S3Service => Map 타입으로 각 값들을 전달한다

GoodsService에서 bucket, region, fileName을 각각 입력받는다

bucket, region, fileName을 각각 입력받아도 fileUrl은 자동으로 구성된다

이로써 바꾼 코드에선 S3에서 파일을 삭제하거나 수정할 때
Files.getFileName()으로 key값을 가져올 수 있다

※수정

2022년 07월 09일

추가적인 구현을 하다보니 fileName보다 url을 사용 할 일이 많다는 것을 알게 되었다
(fileName은 delete할 때 밖에 사용할 일이 없었다)
특히 게시했던 사진/동영상 파일들을 게시글을 수정할 때,
FE에게 url을 받을 일이 많아져서 다시 한 번 로직을 수정하였다

삭제 로직에서만 fileName(key)이 필요하므로 삭제시 url에서 fileName을 추출한다

파일 테이블은 원래대로 fileUrl값만을 가지게 되었고, 서비스들도 url만을 이용하게 롤백하였다