개인과제를 오늘 마무리 했는데 설계 때부터 완성까지 과정을 정리해볼까 싶다. 내일부터 새로운 주차가 시작되는데 얼마나 할지 모르겠지만 일단 시작.

요구사항

1. 전체 게시글 목록 조회 API
   • 제목, 작성자명, 작성 날짜를 조회하기
   • 작성 날짜 기준으로 내림차순 정렬하기
2. 게시글 작성 API
   • 제목, 작성자명, 비밀번호, 작성 내용을 입력하기
3. 게시글 조회 API
   • 제목, 작성자명, 작성 날짜, 작성 내용을 조회하기
     (검색 기능이 아닙니다. 간단한 게시글 조회만 구현해주세요.)
4. 게시글 수정 API
   • API를 호출할 때 입력된 비밀번호를 비교하여 동일할 때만 글이 수정되게 하기
5. 게시글 삭제 API
   • API를 호출할 때 입력된 비밀번호를 비교하여 동일할 때만 글이 삭제되게 하기
6. 댓글 목록 조회
   • 조회하는 게시글에 작성된 모든 댓글을 목록 형식으로 볼 수 있도록 하기
   • 작성 날짜 기준으로 내림차순 정렬하기
7. 댓글 작성
   • 댓글 내용을 비워둔 채 댓글 작성 API를 호출하면 "댓글 내용을 입력해주세요" 라는 메세지를 return하기
   • 댓글 내용을 입력하고 댓글 작성 API를 호출한 경우 작성한 댓글을 추가하기
8. 댓글 수정
   • 댓글 내용을 비워둔 채 댓글 수정 API를 호출하면 "댓글 내용을 입력해주세요" 라는 메세지를 return하기
   • 댓글 내용을 입력하고 댓글 수정 API를 호출한 경우 작성한 댓글을 수정하기
9. 댓글 삭제
   • 원하는 댓글을 삭제하기

Database 설계

@ 아래 두개가 최종구현 단계에서 정해진 데이터베이스이다. 왜 이렇게 설계하게 된건지 이유를 말해보겠다.

Note

name	type	limit	nullable	description
noteId	Number	Unique:true	false	게시글ID, 1부터 시작하여 글작성 시마다 1 증가
author	string	Min:1 Max:20 Unique:false	false	글 작성자
pw	string	Min:1 Max:30 Unique:false	false	글 비밀번호
title	string	Min:1 Max:50 Unique:false	false	글 제목
content	string	Min:1 Max:1000 Unique:false	false	글 내용
createdAt	Date	default:today Unique:false	false	글 작성 날짜

@ 일단 각 테이블과 속성의 이름부터 정한다. 게시글이니까 post가 가장 직관적이지만 메소드 post와 왠지 같은 이름은 피하고 싶었다. 여러 후보 중에 note가 가장 나을 것 같았다. 그외는 작성날짜를 createdAt으로 주로 쓴다고 하여 그걸 채용.
@ 노트와 코멘트 둘다 숫자타입 id를 만들었는데 몽고DB를 써보니 기본적으로 id값이 생성되었지만 그걸 안쓰고 그냥 만들어 썼다. 구현 도중 단계에서는 이 id값들도 썬더클라이언트에 body값으로 직접 입력해서 db에 넣었는데 마무리 단계에서 자동으로 테이블 중에서 각각 중복 안되는 방법으로 자동 증가하도록 수정하였다.

Comment

name	type	limit	nullable	description
noteId	Number			FK
commentId	ObjectId	Unique:true	false	댓글ID, 각 글 마다 1로 시작하여 댓글 달릴 때마다 1 증가
author	string	Min:1 Max:20 Unique:false	false	댓글 작성자
content	string	Min:1 Max:200 Unique:false	false	댓글 내용
createdAt	Date	default:today Unique:false	false	댓글 작성 날짜

@ 이게 적절한 설계일지 모르겠으나, 댓글테이블에는 PK가 없다. 외래키로 noteId를 갖고 오고 그 각 글마다 댓글Id가 각각 1부터 시작한다고 생각했다. 어디에 달린 댓글이든 그냥 공통으로 중복안되게 매번 증가하는 id값을 넣어줘도 될지도 모르는데, 그냥 좀 이상해보였다. 나중에 더 경험해보면 뭐가 맞는지 판단이 될지도.

API 설계

@ 처음엔 메소드와 path를 먼저 정한다.
@ post는 request body로 값들을 넣을꺼니까 prameter가 필요 없었고, body에 넣을게 많다.
@ get은 전체조회의 경우에는 parameter가 필요 없었지만, 특정 게시글을 조회하거나, 특정 게시글의 댓글들을 조회할 경우에는 noteId를 파라미터로 넣었다. 그리고 get은 body에 값을 넣을 수 없다고 한다. 정확히는 express.js 단계에선 되는데 프론트로 가면 안되기에 여기서도 하면 안된다고 함.
@ put, delete 경우에는 어떤 글을 수정할건지 id를 파라미터로 넣었고. 비밀번호와 수정할 내용들은 바디로 전달했다. 특히 코멘트의 경우 파라미터를 두번이나 경로에 써줬는데. 몇번 글의 몇번 댓글 이런 개념으로 삭제하는게 직관적이라고 해야되나.
@ 전체적으로 리스폰스부분이 굉장히 부실하다. 왜냐면 이게 실제 html 파일을 가지고 구동되는 거면 그걸 감안해서 글 삭제 시 다시 글목록으로 돌아간다던가하는 경우도 생각해야할 거고. 각종 에러 상황에 대한 처리도 필요할 건데 아직 1주차라서 다른 거 먼저 하느라 상대적 신경을 덜 쓴 부분.

Note

Method, URL	Function	request	response	Description
POST /note	게시글 작성	{ "author" : "글쓴이", "pw" : "12345", "title" : "글제목", "content" : "글내용" }	생성한 글 내용
GET /note/:noteId	게시글 조회		{ "note":{ "author":"글쓴이", "title":"글제목", "content":"글내용", "createdAt":"2022-07-28T06:17:51.111Z" } }
GET /note	전체 게시글 목록 조회		{ "note" : [ { "author":"", "title":"", "createdAt":"2022-07-28T07:31:16.913Z" }, { "author":"", "title":"", "createdAt":"2022-07-28T07:31:16.913Z" }, ... ] }	날짜로 내림차순 정렬
PUT /note/:noteId	게시글 수정	{ "pw" : "12345", "title" : "수정할 제목", "content" : "수정할 내용" }	수정한 글 또는 "없는 데이터입니다."
DELETE /note/noteId	게시글 삭제	{ "pw" : "12345" }	실패 시 "없는 데이터입니다."

Comment

Method, URL	Function	request	response	Description
POST /comment/:noteId	댓글 작성	{ "noteId" : 1, "author" : "댓글작성자", "content" : "댓글내용" }	댓글 내용 미입력 시 : "댓글 내용을 입력해주세요"
GET /comment/:noteId	댓글 목록 조회		{ "comment": [ { "author" : "", "content": "", "createdAt": "2022-07-28T10:52:23.688Z" }, { "author" : "", "content": "", "createdAt": "2022-07-28T10:52:22.634Z" }, ... ] }
PUT /comment/:noteId/:commentId	댓글 수정	{ "content" : "수정할 댓글" }	수정된 댓글 수정 내용 미입력 시 : "댓글 내용을 입력해주세요" 수정할 데이터를 못찾았을 시 : "없는 데이터입니다."
DELETE /comment/:noteId/:commentId	댓글 삭제