회원 등록 API

HTML의 웹 페이지가 아닌 API에서의 JSON 형태로 데이터를 전달할 때의 컨트롤러를 설계한다.

 

 

 

API 설계의 잘못된 예

@RestController // api 설계할 때에는 RestController 사용
@RequiredArgsConstructor
public class MemberApiController {

    private final MemberService memberService;

    @PostMapping("api/v1/members")
    public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member) {
        
        Long id = memberService.join(member);
        return new CreateMemberResponse(id);
    }
    
    @Data
    static class CreateMemberResponse {
        private Long id;

        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }
}

위와 같이 설계를 하면 문제점이 있는데, 그 문제점은 Member라는 엔티티를 그대로 사용했다는 것이다. 이렇게 사용하면 api가 여러개 필요할 때가 있는데, 그 때마다 요구 사항이 다른데 하나의 엔티티에 @NotEmpty 를 넣으면 모든 api의 요구 사항을 충족할 수 없고 전부 다 공백이면 안되기 때문이다.

그리고 api 스펙에서 변수의 수정사항이 발생한다 했을 때 하나의 엔티티로 설계하면 수정사항이 다른 api에 모두 적용되어서 효율적이지 않다.

 

 

API 설계는 이렇게 하기 (API마다 별도의 Dto 만들기)

@RestController // api 설계할 때에는 RestController 사용
@RequiredArgsConstructor
public class MemberApiController {

    private final MemberService memberService;

    @PostMapping("api/v2/members")
    public CreateMemberResponse saveMemberV2(@RequestBody @Valid CreateMemberRequest request) {
        
        Member member = new Member();
        member.setName(request.getName());

        Long id = memberService.join(member);
        return new CreateMemberResponse(id);
    }

    @Data
    static class CreateMemberRequest {
        private String name;
    }

    @Data
    static class CreateMemberResponse {
        private Long id;

        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }
}

Response 뿐만 아니라 Request 또한 별도의 Dto를 만들어서 설계해줘야 한다. 위에서 말한 문제점이 해결된다. 즉, api 별로 별도의 검증이 가능하고, 엔티티가 변경되어도 api의 스펙이 변하지 않는다.

따라서 api 설계에서는 무조건 별도의 Dto 클래스를 만들어서 설계를 해줘야한다.

 

 

 

 

Postman으로 데이터 보내보기

Postman으로 hello라는 name을 가진 데이터를 보내보면 잘 작동하는지 확인할 수 있다.