📝 서론

본격적인 프로젝트 시작에 앞서, API 명세를 작성하였다.
빠른 API 명세서 작성을 위해 Notion을 활용하였다.
API 명세 작성 과정에서 학습, 고민, 해결 한 내용들을 기록한다.

✏️ 학습 내용

1. URL 작성 컨벤션

• URL은 소문자를 사용한다.
  • userName -> user-name
• _ (밑줄) 대신 - (하이픈) 을 사용한다.
  • 밑줄의 경우 특정 상황 (링크 전체에 밑줄이 쳐지거나, 주소창에 가려 URL의 밑줄이 보이지 않는 경우를 방지)
• REST API
  • URL은 명사를 사용하여 리소스를 명시하고, 동작은 Method를 사용하여 명시한다.

🧐 고민

1. 데이터의 중복 & 유지보수 VS 안정성

서버에서 내려주는 JSON 데이터가 형태가 비슷했다.
이를테면, 프로젝트 목록 페이지에서와 상세 페이지에서 모두 대부분의 프로젝트 정보를 필요로 한다.
하지만, 프로젝트 목록에서는 프로젝트의 런칭 시작 날짜가 필요하지 않으며, 상세 페이지에서는 프로젝트 한줄 소개가 필요하지 않다.
이런 경우, 똑같은 형태의 데이터를 내려주어 데이터의 중복을 없애고, 생산성을 높이는 것이 좋을까?
아니면, 혹시 모를 상황을 대비하기 위해 모든 데이터를 별개의 형태로 만들고, DTO도 모두 개별적으로 사용하는 것이 좋을까??

DTO에 관한 고찰 -> 어떻게 만들것인가 부분
위 작성자는 모든 요청에 대해 클래스를 새로 만드는 방법을 선택하였다.

모든 요청에 대한 클래스를 새로 만든다면, Interface를 만드는 방법으로 생산성을 조금이나마 증진시킬 수 있지 않을까

2. 한 페이지에서의 다양한 요청

프로젝트의 세부 페이지에서는 프로젝트 기본 정보와 창작자, 프로젝트 세부정보를 보여주어야 한다. 이 때, 프로젝트 세부 정보는 다시 3개의 탭으로 구성되어 있다.
이 경우, 프로젝트 세부 정보 페이지에 접속했을 때, 각 정보를 요청하는 3개의 개별 요청을 사용해야 할까? 아니면, 프로젝트 세부 정보 페이지에 접속하는 순간 하나의 요청에 세개의 데이터를 모두 실어 보내야 할까?

우선, 이번 프로젝트에서는 하나의 요청에 모든 데이터를 전달해 주는 방식을 사용했다.
프론트엔드에서 3개의 다른 요청을 사용해 하나의 페이지를 구성하는 방법이 존재하는 지 궁금해 졌다.

3. DB에서는 동적 크기 배열을 어떻게 저장해야 하는가?

프로젝트에서 사용하는 판매 목록은 개수가 정해져 있지 않다. 이런 동적 크기의 정보를 어떻게 저장해야 할까?

잠깐의 고민 결과는 최댓값을 지정해 주는 방식이다. 하지만, 해당 방식은 다음과 같은 문제점이 예상된다.
1. 적은 수의 데이터 저장시에도 최대 개수만큼의 메모리를 할당하는 메모리 낭비
2. 데이터의 저장 개수가 제한적임

DB를 더 공부해야 한다.

4. 프론트엔드에서의 상태 저장과 서버

HTTP 통신은 기본적으론 Stateless 를 지향한다고 알고 있다. 이 개념이 "프론트 엔드에서는 값을 저장하지 않는다." 라는 뜻은 아닌 것 같다. 프론트엔드에서도 자체적으로 값을 다음 페이지로 넘겨줄 수 있다고 한다. 그런데, 프론트엔드가 서버를 가지지는 않는다고 한다. 이는 아마 프론트엔드에서 사용하는 React 같은 프로그램의 메모리에 변수를 저장한다는 것 같다.

사용자의 선택 정보가 다음 페이지에 사용되어야 할 경우, 해당 정보는 어디에 저장하는 것이 가장 옳은 선택인 걸까?

• 쿠키 정보로 가지고 있거나, 캐시 메모리에 저장해 두는 게 옳은가?
• 프론트엔드에서 사용하는 메모리에 저장해 두는 것이 옳은가?
• 매 요청마다 서버에서 데이터를 내려주는 것이 옳은가?