[엘리스 SW 트랙] 1차 프로젝트 : 오피스아워 코멘트 8주차 - 2

 

Data Schem 코멘트 반영 된 ERD

프로젝트 전체 Data schema

카테고리 구조 논의 ERD

 

API 관련 코멘트

• 카테고리 관련 API & 데이터 스키마를 작성하다보니 접근 방식이 다양하게 나오는데요. 이 방법들을 어떻게 채택하면 좋을까요? 나중에 카테고리 정보를 이용해 상품 리스트들을 필터하는 것도 고려중입니다.
  • 카테고리의 기준을 잡아야 합니다. 단순히 카테고리의 계층 구조만 전달할 것인지, 아니면 카테고리에 많은 정보를 담아서 보낼 것인지 등 기준이 명확해야 혼동이 오지 않습니다.
  • 상품 리스트 필터를 고려해서 카테고리에 다양한 정보를 넣고 싶으신거죠? 그렇다면 현재 작성해오신 구조보다는, Product의 데이터 스키마에 카테고리 값이 들어가 있는 형태가 더 편하실 겁니다. 카테고리는 단순히 계층 구조, 그러니까 대분류/소분류 계층 정보만 담고 있게 하는 거죠. 그게 더 훨씬 깔끔할 겁니다.
  • 실제 커머스에서 중요하게 생각하는 부분 중 하나가 이 카테고리인데요, 고려하신 부분들이 실제 현업에서도 많이 논의가 되는 부분입니다. 커머스에서는 카테고리를 어떻게 사용하느냐에 대한 중요도도 꽤 높기 때문이에요. 후에 시간이 된다면 단순한 데이터 구조에서 좀더 복잡한 구조를 고려해보시는 것도 권장해드립니다. 
• 기능 요구사항 중에 User의 role 별로 접근하는 페이지가 다른 경우가 있는데요. 동일한 path를 사용하고 현재 유저의 role 값을 가져와 확인하여 사용하는 방법이 좋은지, 아니면 role 에 따라 path를 다르게 가져가는게 좋은지 궁금합니다.
  • 두 가지 방법이 있습니다. 첫번째로 동일한 path를 가져가되, user role에 따라 response를 다르게 해주는 방법인데요. 이 방법은 accessToken을 이용해서 사용자의 role을 구분하는 방법입니다. 로그인 할 때 accessToken을 어떻게 하시냐에 이 방법이 쓰일 수도 있고, 아닐수도 있겠네요 :) 
  • 두 번째 방법은 관리자 전용 API를 만들어주는 겁니다. 대신 이 방법의 경우 API path에 admin이 들어가야합니다. 이렇게 들어가게 된다면 API 사용자가 누군지 좀 더 명확해지겠죠. 음.. 저는 admin API를 분리해서 사용하시는 걸 추천해드리고 싶네요. 다른 기능에서도 관리자가 전용으로 사용해야하는 페이지와 API가 있으니까, 이 방법이 더 나아 보입니다. 
• API path를 작성해 오긴 했는데.. 이런식으로 장성하는게 맞을까요?
  • 백엔드 쪽에서 API를 작성할 때, 공통적으로 따라야 하는 가이드 라인이 있습니다. 실제로는 많은 가이드 라인이 있는데, 우리 프로젝트에서는 CURD만 사용하니 그 부분에 대해서만 알려드릴게요. 추가적인 부분은 한번 찾아서 읽어보시는 걸 권장드립니다.
  • API 의 path는 정보의 자원, 즉 리소스를 표현해야합니다. "delete, add" 같은 행위를 표현하는 동사가 들어가서는 안되고요. 반드시 동사가 아닌 명사로 표기 되어야합니다.
  • 그러면 "행위"는 어떻게 표현해야할까요? 행위는 HTTP method(GET, POST, DELETE, PUT, PATCH)로 표현합니다. 그래서 "delete" 나 "add" 같은 게 path에 표시되지 않아도되는 거죠.
  • path의 마지막에는 슬래시를 포함하지 않습니다. 그리고 PATCH, POST의 경우 데이터 요청할 정보를 보낼 때는 param이 아니라 Request body에 넣어주셔야해요. 쿼리를 넣는 것은 GET, DELETE에만 넣는 것이라고 생각하시면 혼동이 덜 될 겁니다.
  • path에 표시되는 리소스들간의 관계가 있을 건데요. 이럴 때는 이렇게 표기해주시면 됩니다. "리소스명/리소스ID/관계가 있는 다른 리소스명" 예시를 들자면 이렇게 되겠죠.

# 리소스 관계 표현 예시 

host/api/schools/:id/class/:id/students

-> 어떤 학교의 한 교실에 속한 학생들의 정보를 불러오는 API

• 아 추가로, 응답 상태 코드들에 대해서 잘 표현해주셨으면 좋을 것 같습니다. 현업에서는 이 코드가 꽤 중요하거든요
  • 응답 상태 코드
    • 200 : 클라이언트의 요청을 정상적으로 수행함
    • 201 : 클라이언트가 어떤 리소스 생성을 요청하고, 해당 리소스가 성공적으로 생성되었을 경우
    • 400 : 클라이언트의 요청 부분이 부적절 할 경우
    • 401 : 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 경우
    • 500 :  서버에 문제가 있을 경우

코멘트 반영 후 API 설계 완료 화면

 

 

#엘리스트랙 #엘리스트랙후기 #리액트네이티브강좌 #온라인코딩부트캠프 #온라인코딩학원 #프론트엔드학원 #개발자국비지원 #개발자부트캠프 #국비지원부트캠프 #프론트엔드국비지원 #React #Styledcomponent #React Router Dom #Redux #Typescript #Javascript