응답 객체
- ApiResponse 객체: 기존 응답을 한 단계 더 래핑한 것
- 부정론
- 예외 상황이 아니면 특별히 code, message를 전달할 필요가 있을까?
- 상태코드로 code가 처리되지 않을까?
- 긍정론
- code는 프론트와 합의하여 사용하는 특정된 코드의 의미임(멘토님)
- 우리 회사 같은 경우 위 방식을 사용하고 있다(멘토님)
- REST를 사용한다면 필요가 적기는 함
- 성공 시에는 동일 코드를 쓰고,
- 에러 코드는 명시된 한 파일에
- 절충: 에러 코드 시에만, code, message 보유한 객체 사용하여 처리 ✅
- 다른 응답 시에는 ResponseEntity<응답객체>
설정 파일(application.yml, build.gradle)
- 멘토님의 경우 기본 환경에서 테스트 사용하고 있음
이미지 처리 부분
- 이미지의 순서 부분
- 본문 예시 { 글자1 [그림1] 글자2 [그림2] 글자3 }
- 본문 예시 { 글자1 [첫번째 이미지 url] 글자2 [두 번쨰 이미지 url] 글자3 }
- 본문 예시 { 글자1 #{이미지링크} 글자2
- 이미지
- 연관관계를 꼭 써야 한다는 집착을 빼자
- 같은 이미지인지 판단해서 처리하지는 말자
url 스타일
- store(메인페이지)
- 민성
- 메인 페이지의 경우 백엔드의 응답에 따라 구성되기 때문에
- 부적절한 네이밍이다.
- 현정
- 메인 페이지를 백엔드에서 구현한다는 의미로 받아들었기에
- 1차적으로 필요한 데이터를 조립해서 보내준다는 것
- 민재
- 메인 페이지가 정적이면 한방 쿼리로 최적화가 가능
- 멘토님
- 부분적 로딩이 필요한지 등 요구사항에 따라서 달라지게 됨
- 커뮤니티 / 스토어 url 분리
- 현정
- 굳이 분리하지 않아도 되지 않을까?