TIL 83 - [ Spring 최종 프로젝트 ( Day 19 ) - S3 문제 이미지 기능 구현, 브로셔 작업 ]

TIL 82 - [ Spring 최종 프로젝트 ( Day 18 ) - S3의 잘못된 사용, 기능 구현 ]

어제 S3를 잘못 사용해서 시간이 지체가 되었지만, 이제 S3 버킷이 프로젝트 단위 기준으로 써야한다는 것을 인지하게 되고, 재구성해서 다시 사용하게 되었다.

그리고, S3Config, S3Upload 하는 클래스들 만들어서 S3가 사용되게 활성화하게 해주었다. 자세한건 윗 글을 참고하면 될 것 같다. 오늘은 이를 토대로 이미지 기능과 기능 구현에 시간을 두었다.

💡 문제 이미지 기능 구현

우선적으로 PostMapping만 해보았다. 컨트롤러와 서비스에서 변화가 생길수 밖에없다. 그래서 여기에 이제 S3Uploader를 추가하게 되고, 서비스 로직도 이에 맞춰서 생성하게 해주었다. 이때 가장 눈에띄게 변화가 생긴건 컨트롤러단이 많이 눈이 갔다.

그래서 이번에 컨트롤러단에 익숙하지 않은 어노테이션, 코드들을 한번 알아보았다.

1️⃣ @RequestPart

보통 @RequestBody를 사용해서 요청값을 받아오는 것이 일반적이었다. 하지만, 이번에 이미지 데이터를 같이 요청 값으로 받으려하니까 @RequestPart라는 어노테이션을 사용한다.

JSON + 이미지 파일 같이 보내기 → 이건 @RequestPart 방식에서만 가능

HTTP 요청에서 multipart/form-data 형식의 "부분(part)" 을 매핑하는 데 사용되는 Spring 어노테이션임.

2️⃣ MultipartFile

• Spring에서 HTTP 요청으로 넘어온 파일 데이터를 추상화한 객체입니다.
• 업로드된 파일에 대한 정보를 쉽게 다룰 수 있게 해주는 인터페이스입니다.

3️⃣ consumes = { MediaType.MULTIPART_FORM_DATA_VALUE }

• 컨트롤러 메서드가 어떤 Content-Type의 요청을 소비(consumes) 할 수 있는지를 명시하는 속성임

🎯 왜 쓰는가?

• 클라이언트가 보낸 요청의 Content-Type이 multipart/form-data일 때만 이 메서드를 실행하도록 제한

 

 

이제 Swagger 에서도 쉽게 사용할 수 있게 설정을 한번 해보아야겠다. 이후 수정과 삭제에서도 기능을 사용할수 있도록 조정해보아야 겠다.

❓ 트러블 슈팅

📅 브로셔 작업

제출일이 얼마 안남아서, 브로셔 작업을 급하게 팀원들과 작성하였다.

프로젝트 소개와, 팀소개, 주요 기능, 기술 스택등 각각 작성하였다. 이제 최종 프로젝트 기간이 얼마 남지 않아서, 미리 준비를 다 하는것 같다. 직접 이렇게 정리해서보니까 기간이 길었던 만큼 많은 것을 사용했구나라는 것을 느낀 시간이었습니다.