ERD → API 매핑 연습

1. 대상 테이블 구조

posts (게시글)

• post_id (PK)
• user_id (FK → users.user_id)
• title
• content
• status (PUBLISHED / DRAFT 등)
• view_count
• created_at
• updated_at
• deleted_at (soft delete)

users (작성자)

• user_id (PK)
• name

comments (댓글)

• comment_id (PK)
• post_id (FK → posts.post_id)
• user_id (FK → users.user_id)
• content
• created_at
• deleted_at

likes (좋아요)

• like_id (PK)
• post_id (FK → posts.post_id)
• user_id (FK → users.user_id)
• created_at

---

2. 테이블 책임을 1줄로 정의하기

사용자는 게시글을 생성하고, 목록과 상세로 조회하며, 작성한 글을 수정하고 삭제할 수 있다.

"이 문장 안에 Create, List, Detail, Update, Delete가 이미 포함되어 있으므로 게시글 기준 API 5개가 자연스럽게 도출된다."

---

3. 게시글 기준 API 5개 (CRUD + List)

1) 게시글 생성 (Create)

• POST /api/posts

요청 DTO (Request)

• title
• content
• status (선택)
• 필요 시 확장: category_id, images 등

응답 DTO (Response)

• post_id
• title
• content
• status
• view_count
• author (user_id, name)
• created_at

---

2) 게시글 목록 조회 (Read - List)

• GET /api/posts?keyword=&sort=&page=&size=&status=

주요 쿼리 파라미터

• keyword: 제목/내용 검색
• status: PUBLISHED/DRAFT 등 필터
• sort: created_at, view_count 등 정렬 기준
• page, size: 페이징

응답 DTO (Response)

• items: 게시글 리스트
  • post_id
  • title
  • status
  • view_count
  • author (user_id, name)
  • created_at
• page_info
  • page
  • size
  • total_elements
  • total_pages

---

3) 게시글 상세 조회 (Read - Detail)

• GET /api/posts/{postId}

응답 DTO (Response)

• post_id
• title
• content
• status
• view_count
• author (user_id, name)
• created_at
• updated_at
• 옵션 필드(필요 시)
  • is_liked (로그인 사용자 기준)
  • comment_count
  • like_count
  •  

---

4) 게시글 수정 (Update)

• PATCH /api/posts/{postId}

PATCH는 부분 수정이며, PUT은 전체 수정이다.

요청 DTO (Request)

• title (선택)
• content (선택)
• status (선택)

응답 DTO (Response)

• post_id
• title
• content
• status
• updated_at

---

5) 게시글 삭제 (Delete)

• DELETE /api/posts/{postId}

일반적으로 soft delete를 적용한다.

처리 방식 예시

• deleted_at을 현재 시각으로 업데이트
• status를 DELETED로 두는 방식도 가능

응답

• 204 No Content
  또는
• 200 OK + deleted_at

---

4. ERD 컬럼 → DTO 매핑 원칙

API 요청/응답 DTO는 기본적으로 ERD 컬럼을 그대로 매핑한다.

• post_id는 URL path 변수로 사용된다.
• user_id는 보통 토큰에서 추출한 로그인 사용자로 결정되며, 요청 바디에 직접 받지 않는 경우가 많다.
• deleted_at은 soft delete 처리의 근거 컬럼이 된다.
• 목록/상세 응답에서 author는 users 테이블과의 관계를 조인하여 구성한다.

---

최종 정리

posts 테이블을 기준으로 ERD를 분석하면 게시글 생성, 목록 조회, 상세 조회, 수정, 삭제의 5개 API가 바로 도출된다.

각 API의 DTO 필드는 posts/users/comments/likes의 컬럼에서 그대로 매핑하며 관계 데이터(author, comment_count, like_count 등)는 조인 또는 집계를 통해 응답에서 구성한다.

이 방식으로 ERD를 먼저 보고, 책임을 1문장으로 정의한 뒤, CRUD+List API를 뽑고 DTO를 컬럼에 매핑하는 흐름을 반복하면
ERD → API 설계 사고가 빠르게 정착된다.