[Step4] 데이터 전송 방식을 일부 변경한다. #5

devjun10 · 2024-03-26T07:33:46Z

📝 구현 내용

회원정보 수정을 Application/Json 방식으로 처리했습니다.

회원정보 수정을 Application/Json 방식으로 변경
인터셉터 처리 추가

✨ 인터셉터

인증/인가가 필요한 API의 공통 로직을 인터셉터로 옮겨, 중복 로직을 제거했습니다.

@Slf4j
public class SessionCheckHandlerInterceptor implements HandlerInterceptor {

    ......

    @Override
    public boolean preHandle(
        HttpServletRequest request,
        HttpServletResponse response,
        Object handler
    ) {
        Long sessionId = getSessionId(request.getCookies());
        validator.validateSessionId(sessionId, response);

        Session findSession = loginUseCase.findSessionById(sessionId);
        log.info("Session:{}", findSession);
        validator.validateSession(findSession, response);

        LoginUser loginUser = new LoginUser(findSession);
        request.setAttribute("loginUser", loginUser);
        return false;
    }

    ......

}

이는 HandlerExecutionChain 내부에 존재하며, Handler를 호출하기 전, 실행됩니다.

public class HandlerExecutionChain {

    private List<HandlerInterceptor> interceptors;
    private final Object handler;

    ......

}

@controller

- Path를 읽어서 Handler를 등록하기 위해 어노테이션 추가 - @controller 어노테이션 리팩토링 *Retention, Target, Documented 추가

- Interceptor 추가 *공통 세션 체크 로직 이동

*어노테이션 기반으로 변경

- 요구사항 정리

- 테스트 전 모든 데이터를 제거하도록 수정

- 실행 방법 추가

- 개행 한 칸씩 제거

kmularise

고생하셨습니다!

kmularise · 2024-03-26T12:54:28Z

app/src/main/java/project/server/app/core/web/user/presentation/LoginController.java

-        String username = request.getAttribute("username");
-        String password = request.getAttribute("password");
-        log.info("username: {}, password: {}", username, password);
+        String username = (String) request.getAttribute("username");


이렇게 리팩토링 하신 이유가 있나요?

인터셉터를 별도로 생성해, 중복되는 로직을 모두 삭제했습니다.

kmularise · 2024-03-26T12:55:22Z

app/src/main/java/project/server/app/core/web/user/presentation/UserInfoSearchController.java


    @Override
-    @GetMapping(path = "/users/{userId}")
+    @GetMapping(path = "/my-info")


path가 바뀐 이유가 궁금합니다!

이 부분은. html과 같게 하려고 경로를 수정했습니다. 처음 설계할 때, 조금 더 신경 써야 했던 것 같습니다.

kmularise · 2024-03-26T12:56:11Z

app/src/main/resources/static/index.html

                            console.error('Error:', error);
+                            localStorage.clear();
+                            document.cookie = 'sessionId=; Path=/; Expires=Thu, 01 Jan 1970 00:00:01 GMT;';
+                            window.location.href = "http://localhost:8080/";


html 관련 내용이긴 하지만, 쿠키 관련 설정이 추가된 이유가 있나요?

기존 로직에는 서버를 재 실행 했을 때도 쿠키가 남아있었습니다. 따라서 에러가 발생하면 로그아웃 처리를 하기 위해 해당 설정을 추가했습니다.

kmularise

리팩토링으로 코드가 더 깔끔해진 거 같아요! 고생하셨습니다!

kmularise · 2024-03-27T01:52:25Z

app/src/main/java/project/server/app/common/configuration/WebConfiguration.java

+        addInterceptors(getBean(InterceptorRegistry.class));
+    }
+
+    @Override


인터셉터를 직접 구현하셨군요! 인터셉터를 구현하신 이유가 있나요? 인터셉터의 역할은 무엇인가요?

각 컨트롤러에서 권한 체크를 하니, 로직의 중복이 발생했는데요, 이를 제거하기 위해 인터셉터를 만들었습니다. 즉, 권한 체크가 인터셉터의 역할입니다.

kmularise · 2024-03-27T01:55:05Z

app/src/main/java/project/server/app/core/web/user/persistence/UserPersistenceRepository.java

    @Override
    public void delete(User user) {
-        String sql = update(User.class, "deleted");
+        String sql = JdbcHelper.update(User.class, "deleted");


JdbcHelper에서 update메소드를 호출할 때 두번째 메소드 파라미터가 유효하지 않은 경우면 어떻게 되나요?

다시 보니, validator가 파라미터 검증을 안 하고 있네요. 이 부분 수정하겠습니다.

@Slf4j @RestController public class UserInfoUpdateController implements Handler { private final UserValidator validator; private final UserLoginUseCase loginUseCase; private final UserUpdateUseCase userUpdateUseCase; ...... @Override @PutMapping(path = "/api/users") public ModelAndView process( HttpServletRequest request, HttpServletResponse response ) { LoginUser loginUser = (LoginUser) request.getAttribute("loginUser"); userUpdateUseCase.update(loginUser, (String) request.getAttribute("password")); response.setStatus(OK); return null; } }

kmularise · 2024-03-27T01:56:44Z

mvc/src/main/java/project/server/mvc/AbstractJsonHttpMessageConverter.java

@@ -0,0 +1,4 @@
+package project.server.mvc;


인터페이스가 아닌 추상클래스로 만드신 이유가 있을까요?

이 부분은 스프링을 참조했는데, 상태를 가질 필요가 있어서 추상 클래스를 사용했습니다.

AbstractJsonHttpMessageConverter.java이 코드 상에서는 상태가 보이지 않는 거 같은데 더 자세히 말씀해주실 수 있나요?

이 부분은 JsonConverter를 구현하려고 했는데, 굳이 구현할 필요가 있을까 싶어 DispatcherServlet에서 간략하게 처리했습니다. 아직 구현되지 않은 부분인데, 이 부분은 그냥 넘어갈까 합니다.

kmularise · 2024-03-27T01:58:05Z

mvc/src/main/java/project/server/mvc/servlet/HttpServlet.java

    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws Exception {
    }
+
+    protected void doPut(HttpServletRequest request, HttpServletResponse response) throws Exception {


PUT 요청과 POST 요청의 차이점에 대해서 설명해주세요!

Post는 자원의 생성, Put은 수정에 사용됩니다. 이미 아실 것 같아서 기본적인 내용은 제외하면, URI 결정, 멱등성 정도의 차이가 존재할 것 같은데, Post는 URI를 서버가 결정하며, Put은 URI를 클라이언트가 상세하게 지정합니다. 즉, Post는 자원의 위치를 모르기 때문에 서버가 이를 관리하며, Put은 어떤 위치에 있는 자원을 수정할 것인지 클라이언트가 알고 있는 것입니다.

멱등성은 같은 행위를 계속해서 반복하더라도 똑같은 결과가 나오는 것을 말하는데요, Put의 경우 같은 행위를 반복하더라도 최종 값으로 덮어 씌워지게 됩니다.

kmularise · 2024-03-27T01:58:59Z

mvc/src/main/java/project/server/mvc/servlet/http/ContentType.java

+import java.util.Arrays;
+import java.util.function.Predicate;
+
+public enum ContentType {


Content Type 이넘으로 만드신 점 좋은 거 같아요 👍

kmularise · 2024-03-27T01:59:32Z

mvc/src/main/java/project/server/mvc/servlet/http/HttpHeaders.java

+        if (contentTypeHeader == null || contentTypeHeader.isEmpty()) {
+            return false;
+        }
+        Optional<HttpHeader> findApplicationJson = contentTypeHeader.stream()


스트림은 for문에 비해 어떤 장점을 가지나요?

Stream은 for 문에 비해 가독성, 체이닝, 백 프레셔, 함수형 프로그래밍 지원 등의 이점이 있습니다. 이중 가장 큰 이점은 함수형 프로그래밍 지원이라고 생각하는데요, 함수형을 사용해서 부수 효과를 제거하고, 어떤 것(What)을 할 지에 집중할 수 있기 때문입니다.

가독성은 상황에 따라 다를 수 있기 때문에 사람마다 조금씩 생각의 차이가 있을 것 같네요.

kmularise · 2024-03-27T02:00:56Z

mvc/src/main/java/project/server/mvc/servlet/http/RequestBody.java

+
+        Map<String, Object> attribute = new HashMap<>();
+
+        String[] bodyArray = parsedBody.split(",");


"," 사소하지만 파싱 기준이 되는 문자열을 static 상수로 두는 것은 어떻게 생각하시나요?

괜찮은 것 같아요. 반영하겠습니다.

kmularise · 2024-03-27T02:02:33Z

...main/java/project/server/mvc/springframework/context/DispatcherServletAutoConfiguration.java

 import project.server.mvc.springframework.annotation.Configuration;
 import project.server.mvc.springframework.web.servlet.DispatcherServlet;

 @Configuration


@Configuration과 @Component의 차이점에 대해서 설명해주세요. 그리고 @Configuration은 어떠한 상황에서 쓰는지 설명해주세요.

@component는 사용자가 만든 클래스를 빈으로 등록할 때 사용합니다. 반면 @configuration은 라이브러리나 다른 외부 컴포넌트, 예를 들어, RestTemplate 같은 이미 제공해주는 것들을 빈으로 등록할 때 사용합니다. 둘을 혼합해서 사용해도 동작은 하는데요, 결국 @configuration도 내부에 @component가 존재하기 때문입니다.

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Component public @interface Configuration { ...... }

kmularise · 2024-03-27T02:03:16Z

mvc/src/main/java/project/server/mvc/springframework/handler/HandlerInterceptor.java

+
+public interface HandlerInterceptor {
+
+    default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {


default 메소드를 사용하신 이유가 있나요?

이 부분은 스프링을 참조했습니다. 오전에 같이 이야기 나눴는데, 추상 메서드로 처리해도 되고, 추상 클래스에 공통 메서드를 둬도 되고, 지금 같이 default 메서드로 처리해도 됩니다. 이 중 스프링이 채택하고 있는 default 메서드로 이를 구현했습니다.

kmularise · 2024-03-27T02:04:20Z

mvc/src/main/java/project/server/mvc/springframework/web/servlet/DispatcherServlet.java

        ModelAndView modelAndView
    ) throws Exception {
+        if (modelAndView == null) {
+            if (request.isContentType(APPLICATION_JSON)) {


getter 메소드와는 어떤 차이점이 있나요?

반환 타입이 boolean 이어서 isXXX를 사용했습니다. 해당 포스팅을 한 번 읽어보면 도움될 것 같습니다.

kmularise · 2024-03-28T10:29:20Z

mvc/src/main/java/project/server/mvc/AbstractJsonHttpMessageConverter.java

@@ -0,0 +1,4 @@
+package project.server.mvc;


AbstractJsonHttpMessageConverter.java이 코드 상에서는 상태가 보이지 않는 거 같은데 더 자세히 말씀해주실 수 있나요?

J-MU

고생하셨습니다~!

J-MU · 2024-04-09T05:52:04Z