[Project] 프로젝트 설계2

Updated:

Categories:

Tags: ,

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

커피주문시스템의 ERD 구현해보기

기본 키는 무조건 bigint

기본 키는 무조건 bigint로 구현하기 → 기본 키는 40억개 정도인데 bigInt 사용한다는 것은 확장가능성을 고려했다는 것이다, 기본 키가 bigint인 것은 규칙 같은 것이고 나중에 타입을 변경하는 것이 어렵기 때문에 처음부터 확장 가능성을 고려하는 것이 좋다.

틀린 부분 : Role

회원의 권한을 Member 필드에 둔 것 ⇒ 이렇게 하면 안되고 따로 테이블을 만들어서 관계설정 해야 한다.

→ 실제로 Security 적용 했을 때 h2 들어가보면 role이 따로 테이블이 만들어져 있었다 ⇒ 1:다로 구현되어있었음

서비스가 한 명의 회원이 여러 개의 권한을 부여할 건지를 생각하고 관계를 구현해야 한다.

  • 다대다로 구현하는 것이 맞지만 이렇게 한 것은 조인이 깊어지면 조회 성능이 떨어지게 된다. 실제로는 권한을 문자로만 확인하기 때문에 일종의 비정규화라고 할 수 있다. 조회를 많이 할 것에 대해서는 비정규화로 돌리거나 이런 경우가 있긴 함.
  • 논리스키마 (논리 스키마는 dependency를 덜어놓고 논리적으로 테이블 설계)이후 물리스키마 , 종속은 물리스키마에 가깝다,
  • 나중에 어떤 기술을 사용할거니까 이렇게 해야지로 하려면 추상화를 최대한 시켜놓고 하는것이 맏
  • 테이블만 생각해야 한다, 추후 적용 해야 하는 기술은 생각하지 말아야 함.

API 문서 작성 필요성

어떤 플랫폼이여도 상관없으므로 작성하는 것이 좋다.

기존에는 TestCode 짠 후 그것을 기반으로 문서화를 진행하였는데 프로젝트 기획 단계에서 API 문서를 작성해두는 것이 중요하다. 그렇게 하려면 테스트 코드를 짜야 하는데 그것보단 미리 API문서를 작성 후 추후에 테스트 코드를 구현하면 그때 다시 문서화를 해도 된다.

작성시 필수로 있어야 하는 내용

  • api 의 URI = 엔드포인트
  • httpMethod
  • parameter
  • body에 담는 데이터 (JSON)- 예시 데이트포함하기
    • 각각의 키에 대한 설명은 꼭 들어가야 함
  • 응답데이터 (성공 시)

    5-1 상태코드

    5-2 바디데이터 : JSON

  • 응답데이터(실패 시)

    6-1 상태코드

    6-2 바디데이트

Gitbook을 이용한 API 문서 작성해보기

이미지나 PDF로 다운 받고 싶었는데 유료 버전이다

위 조건을 가지고 API를 작성하였는데 부족했고 몰랐던 부분은 아래 관련 규칙과 같다.

Spring에서는 enum으로 구현해서 이걸 API 문서에는 어떻게 적어야 하나 고민했는데

다시 생각해보니 HTTP 통신 시 JSON 형식으로 데이터를 주고 받기 때문에 JSON 에서 사용하는 타입으로 작성해야한다.

그리고 파라미터 관련된 부분에 있어서 get 같은 경우는 바디가 없기 때문에 파라미터를 명시해 주어야 한다.

API 문서 관련 규칙

  • API 문서의 타입은 JSON

    API 문서에서 사용되는 데이터 타입은 JSON에서 사용하는 타입이어야 한다.

    • 예시: string, number, boolean, array, object
  • enum 없음

    JSON 스펙에는 기본적으로 enum이라는 타입이 없기 때문에, 값을 열거할 필요가 있을 때는 명시적으로 설명하거나, 문자열이나 숫자 배열로 표현한다.

  • GET 요청의 바디 제한

    GET 메서드는 데이터 요청을 위해 사용되며, 일반적으로 바디를 포함하지 않는다. 데이터는 일반적으로 쿼리 매개변수로 전달된다.

    • 예시: GET /users?id=12345

Project 카테고리 내 다른 글 보러가기

Leave a comment