• 목차

3단계 종료

1. API Response응답 결과에는 올바른 정보를 담는다.

httpStatus.created는 자원의 생성이 잘 되었음을 의미한다.

그리고 생성된 자원에 대해서 요청 메세지를 Location 헤더로 응답한다고 한다.

그래서, 나는 구간(Section)을 생성해서 저장했으므로 해당 구간의 아이디를 Location에 담아줬지만,

이렇게 받환받은 Location에 매핑되는 구간조회 API는 존재하지 않으며 사실 필요도 없다.

line을 조회하면 section정보를 얻을 수 있기에 Location은 line조회 path를 반환하는게 맞다.

201 Created

2. dto↔entity 변환 로직은 DTO나 Entity에게 책임을 주도록 하자.

private Section createSection(SectionRequest request) {
	return Section.Builder()
                .upStation(findStationById(request.getUpStationId()))
                .downStation(findStationById(request.getDownStationId()))
                .distance(request.getDistance())
                .build();
}

기존에 request를 Section으로 변환해주는 서비스계층 메소드였다.

다른 많은 dto↔entity 메소드는 각각의 dto나 entity에 넣어놓고 해당 메소드만 서비스계층에 뒀던 이유는 상행역(upStation)과 하행역(downStation)의 아이디를 통해 조회를해서 Station Entity를 받아올 필요가 있었기 때문인데, 이 부분은 그냥 서비스 계층에서는 해당 지하철역 엔티티를 조회한다음 이 엔티티들을 파라미터로 넘겨서 DTO에서 Entity를 생성하도록 코드를 변경했다.

3. dto↔entity의 로직은 entity보다는 dto나 converter를 이용하자.

dto는 view의 요구사항에 맞춰 만들어진 객체이기에 요구사항 변경에따른 변경이 잦은편이다.