Skip to content
This repository has been archived by the owner on Aug 13, 2022. It is now read-only.

Feature/#2/login #6

Merged
merged 8 commits into from
Sep 18, 2021
Merged

Feature/#2/login #6

merged 8 commits into from
Sep 18, 2021

Conversation

jsy3831
Copy link
Collaborator

@jsy3831 jsy3831 commented Sep 11, 2021

No description provided.

Copy link

@f-lab-atin f-lab-atin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

에러 및 응답에 대한 코드에 대한 개발을 하셨는데
회원가입 및 캐싱에 대한 처리도 이어서 개발해주세요.

@GetMapping("/{id}")
@LoginCheck
public UserDto getUserInfoById(@PathVariable @NotBlank String id) {
@GetMapping("/myInfo")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

URL 주소는 가급적 RESTful하게 작성하는 것이 좋습니다.
대문자는 사용하지 않고 "-"를 구분자로 사용합니다.

public enum ErrorCode {

/* 401 UNAUTHORIZED */
NOT_LOGIN(HttpStatus.UNAUTHORIZED, "로그인된 사용자 정보가 존재하지 않습니다."),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CustomException, ErrorCode, ExceptionAdvice, ErrorResponse가 너무 강하게 결합되어 있습니다.

CustomException을 날릴 때, ErrorCode를 지정해서 발생시키고 있는데요
CustomException이라는 예외는 단순 에러코드를 전달하는 것 외에는 에러코드 안에 내용을 보기 전에 어떤 에러인지 명확하지가 않습니다.
또한 이 예외 안에 들어가는 ErrorCdoe에는 HttpStatus 코드가 들어가 있습니다.
예외는 서비스단에서 발생을 시키고 있으며, 서비스단에서 발생하는 예외는 Controller단(Presentation Layer)과는 분리가 되어있어야 하는데 서비스단에서 발생한 예외가 Controller단에 사용자에게 어떻게 응답을 할지에 대한 로직까지가 결합이 되고 있습니다.

로그인 서비스 로직을 처리할 때 사용자 로그인이 실패했다는 예외를 통해 알려주기만 해야하는데, 사용자 응답까지 다 결합하는 것은 레이어별 로직 분리가 안되게 됩니다.

그래서 예외 발생시 사용자에게 전달한 메시지와 HttpStatus코드는 service layer와 결합이 되지 않게 해주세요.


@Getter
@Builder
public class ErrorResponse {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ErrorResponse는 현재의 코드를 보면
에러가 발생할 때에만 ResponseEntity에 들어가는 데이터입니다.

그런데, 클라이언트 입장에서 생각해보면
응답 데이터의 body에 성공시에는 userDto데이터가, 실패시에는 ErrorResponse 객체가 들어가 있게 됩니다.
API 응답 포맷은 일관성이 있어야 하는데, 이렇게 되면 클라이언트 입장에서 개발이 난해해질 때가 많고 서버측에서도 유지보수 측면에서 좋지 않습니다.

API 요청에 대한 메시지와 코드 등에 대한 값을 전달을 하려면 성공시나 실패시에나 동일하게 전달을 해줘야 합니다.
ErrorResponse에 대한 명칭을 정상 상황에서도 처리할 수 있는 형태로 변경하고 정상시에도 이 객체를 응답하게 해주는 방법이 있고

또는 ResponseEntity대신에 별도의 응답 클래스를 만들어서 쓰는 방법도 있습니다. (이 ErrorResponse대신에)
아래와 같은 형태의 코드라고 보시면 될꺼 같은데 참고하세요

public class Response<T> {
    private String code;
    private String message;
    pirvate T body;
}

@ResponseStatus(HttpStatus.BAD_REQUEST)
public String illegalArgumentException(IllegalArgumentException e) {
return e.getMessage();
@ExceptionHandler(ConstraintViolationException.class)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

해당 예외에 대한 StatusCode를 정의하는 것은 아래 어노테이션으로 할 수 있습니다.
@ResponseStatus(HttpStatus.BAD_REQUEST)

@jsy3831 jsy3831 changed the base branch from main to develop September 13, 2021 06:00
@jsy3831 jsy3831 closed this Sep 18, 2021
@jsy3831 jsy3831 reopened this Sep 18, 2021
@jsy3831 jsy3831 merged commit f579dda into develop Sep 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants