프로그램 상세 페이지에 필요한 정보는 크게 두 종류이다.
해당 프로그램에 대한 정보 + 해당 프로그램을 신청한 인원 리스트
처음 응답 API 스펙을 설계할 땐 ProgramDto.Response
클래스에 List<ApplyDto.Response>
필드를 추가해서 한 번에 넘기는 방식으로 했다.
public class ProgramDto {
@Schema(name = "프로그램 응답 API 스펙", title = "프로그램 응답 API 스펙")
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@Builder
public static class Response {
//program 정보
...
@Schema(title = "프로그램 이미지 리스트")
private List<ApplyDto.ResponseWithUser> applies;
}
}
public class ApplyDto {
@Schema(name = "프로그램 신청 응답 API 스펙 (유저 정보 포함)", title = "프로그램 신청 응답 API 스펙 (유저 정보 포함)")
@Getter
@NoArgsConstructor
@AllArgsConstructor
@Builder
public static class ResponseWithUser {
@Schema(description = "신청 ID", example = "1")
private Long id;
@Schema(description = "신청 프로그램 ID", example = "1")
private Long programId;
private UserDto.Response user;
@Schema(description = "신청 시간", example = "2022-09-18 10:11:22", pattern = "yyyy-MM-dd HH:mm:ss", type = "string")
@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd HH:mm:ss", timezone = "Asia/Seoul")
private LocalDateTime createdTime;
}
}
그 후 프론트엔드 팀원과 페이지 구성에 대해서 회의를 하다보니 프로그램 신청 인원에 대해서 페이징 처리가 필요했다. 신청 인원이 많을 경우에는 페이징를 해서 보여주는 것이 유저 경험 측면에서 더 나을 것이라고 판단했다.
하지만 그러기 위해서는 프로그램 신청 인원 리스트 조회에 대한 API가 따로 있어야 했다. 페이지마다 ?page=1&size=15
이런 식으로 요청을 새로 보내야 하기 때문이다.
그래서 상세 페이지를 조회할 때 두 종류의 정보를 분리해서 프로그램 정보 조회 API 요청 따로, 신청 인원 리스트 조회 API 요청 따로 응답도 따로 보내는 것으로 설계를 변경했다.
'프로젝트 > DailycluB' 카테고리의 다른 글
DB Schema 설계 (0) | 2022.11.03 |
---|---|
검색/필터링 기능 (Querydsl) (0) | 2022.10.02 |
Entity와 DTO의 사용 범위는 어떻게 해야 할까? (0) | 2022.09.22 |
지역 정보를 Enum으로 할까 테이블로 할까? (@Converter) (0) | 2022.09.19 |
날짜/시간 정보 API로 주고 받기 (0) | 2022.09.18 |
댓글