개발 진행 #3

DB 연결하기

MySQL DB와 연결하고 실제 프론트엔드에서 추가한 데이터가 백엔드를 거쳐 DB로 저장되는지 확인했다.

MySQL 연결

spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/"스키마 이름 기입"?useSSL=false&useUnicode=true&serverTimezone=Asia/Seoul

spring.datasource.username= MySQL 유저 이름 기입
spring.datasource.password= MySQL 비밀번호 기입

spring.jpa.hibernate.ddl-auto=update
spring.jpa.properties.hibernate.format_sql=true

CORS 에러 처리

예전 API 연결 셰션때에는 그냥 @CrossOrigin 만으로도 깔끔히 처리됐지만, 이번에는 JWT 토큰의 도입으로 인해 추가적인 조치가 필요했다. 따라서, SecurityFilterConfig에서

@Bean
    public SecurityFilterChain securityFilterChain(
            HttpSecurity http,
            JwtTokenProvider jwtTokenProvider
    ) throws Exception {

        http
                .cors(cors -> cors.configurationSource(corsConfigurationSource()))
                .csrf(csrf -> csrf.disable())
                .sessionManagement(sm -> sm.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
                .formLogin(form -> form.disable())
                .httpBasic(basic -> basic.disable())
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers(HttpMethod.OPTIONS, "/**").permitAll() // 이걸 추가해야 프론트엔드에서 오류가 안 났다.
                        .requestMatchers(
                                "/users/signup",
                                "/users/login",
                                "/swagger-ui/**",
                                "/v3/api-docs/**",
                                "/h2-console/**" // 없어도 됨.
                        ).permitAll()
                        .anyRequest().authenticated()
                )
                .addFilterBefore(
                        new JwtAuthenticationFilter(jwtTokenProvider),
                        UsernamePasswordAuthenticationFilter.class
                );
        return http.build();
    }

cors.configurationSource 항목을 추가해주고, 그와 관련된 내용을 빈에 추가했다.

@Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration config = new CorsConfiguration();

CSRF는 Stateless + JWT 구조에 맞게 비활성화했다.

Wears (착용 기록) API 설계 및 구현

착용 기록과 관련된 API를 다음과 같이 설계 및 구현했다.

• 착용 기록 생성 (POST /api/wears)
• 특정 날짜 착용 기록 조회 (GET /api/wears?date=YYYY-MM-DD)
• 착용 기록 수정 (PATCH /api/wears/{wearId})
• 착용 기록 삭제 (DELETE /api/wears/{wearId})

수정/삭제는 본인 소유 데이터만 가능”하도록 사용자 검증 로직을 추가했고, 이는 추후 클래스로 재구성이 가능할 것이라고 생각했다. 본인 소유의 데이터가 아닌 경우 커스텀 Exception을 정의하고 처리해서 오류의 원인을 명확하게 밝혔다.

오류를 정확하게 분리하는게 중요하다고 느꼈는데, 프론트엔드 측에서는 CORS, CSLF, Validation 실패가 모두 403처럼 보일 수 있기 때문이다.

• 삭제 API의 경우 ResponseBody 없이 204로 응답하도록 설계했다.

다음주까지 넘어야 할 큰 산

의상 추천 로직은 어느정도 가닥이 잡혔다. 완전 배제가 아닌 우선순위에서 밀리고, 가장 적합한 의상을 추천해줘야 하기 때문에 점수 차감제로 알고리즘을 생각했다.

고려 요소는 비 여부, 온도 기반 계절 판단, 전날 착용한 옷 등이고, 추후 구현할 OUTFIT, LIST API를 기반으로 사용자가 이전에 저장해놓은 프리셋 코디가 상황에 적합할 경우 그 조합을 우선 추천하도록 설계했다.

또한, 원피스에 대해 짚고 넘어가야 했는데, 원피스 특성상 상의 + 하의가 합쳐진 옷이기 때문에 이를 어떻게 구현해야 하는지에 대한 문의가 들어왔다. 이에 DRESS라는 독립 카테고리를 만들고 추가하기로 했다. 단순하지만 현실적인 도메일 모델링의 중요성을 채택했다.