🌈 DB 설계
🌈 1. 하이라이트 저장
POST /create/highlight
왼쪽은 입출력예시, 오른쪽은 postman 으로 테스트한 출력결과다.
DBeaver에서 해당 레코드로 잘 추가된 것을 볼 수 있다.
요구하는 parameter 을 모두 주지 않으면 400 에러를 보냈다.
🌈 2. 하이라이트 수정
PATCH /update/highlight
하이라이트 생성에서 테스트로 넣었던 레코드가 수정된 것을 알 수 있다.
('라이너 사전과제입니다' -> '변경된 텍스트 입니다.)
요구하는 parameter 을 모두 주지 않으면 400 에러를 보냈다.
DB에서 검색이 안되는 값이 들어오면 404 에러를 보냈다.
(user의 시드를 3개만 넣어둔 상태이다.)
🌈 3. 특정 페이지 하이라이트 정보 가져오기
GET /read/texts
최근에 업데이트 된 순서로 값을 가져와야한다.
7번 데이터를 추가해서 테스트를 했다.
요구하는 parameter 을 모두 주지 않으면 400 에러를 보냈다.
🌈 4. 모든 하이라이트 정보(페이지, 텍스트) 가져오기
GET /read/all
페이지도 최근 순으로 정렬해야하고, 하이라이트도 역순으로 정렬해야한다.
요구하는 parameter 이 충족되지 않으면 400 에러를 보냈다.
🌈 5. 하이라이트 삭제
DELETE /delete/highlight
id가 5번인 레코드가 삭제되었음을 알 수 있다.
요구하는 parameter 이 충족되지 않으면 400 에러를 보냈다.
🌈 6. 유저의 하이라이트 테마 변경
PUT /change/theme
id 가 1,2,3 인 레코드의 colorHex 를 변경했다.
원래 테마가 1이었던 걸 2로 바꾸었다.
🌈 후기
- 더 해보고 싶은 부분
-
스키마 User_Page 테이블명을 highlight 로 변경하고 싶다.
처음에는 입출력예시에서 highlightId가 단순히 pageId와 같은 내용을 담고 있는줄 알았다. (같은 값을 갖고있어서 착각했다.)
하지만 pageId는 도메인에 관련된 id이고, highlightId는 텍스트에 관련된 id 라는 걸 구현하다가 깨달았다. -
get, delete 메소드는 query param으로 요청받고싶다.
query 로 진행했던 경험이 많지않아서, 전부 body parameter로 통일했다.
시간여유를 두고 도전해봐야겠다. -
라우팅을 단순하게 CURD 로 나누었는데, 더 직관적으로 나누고싶다.
규모가 작아서 가능한 라우팅이라고 생각한다.
create.js 같은 파일이름보다 컨텐츠를 나타내는 이름을 고민해봐야겠다.
- 좋았던 부분
-
다양한 HTTP 메소드를 사용할 수 있어서 좋았다.
지난 프로젝트때는 2가지정도로 전부를 구현했어서 아쉬웠던 경험이 있다.
이번에는 5가지의 메소드를 활용해봤다.
앞으로 개발을 할 때, 나눠진 것에 대해 잘 활용하고 싶다. -
status code를 신경써서 정해보았다.
상태코드에 깊게 생각해보지 않았는데, 굉장히 유용하다는 것을 깨달았다.
다양한 예시들을 더 찾아보고 어떻게 해야 더 적절하게 쓸 수 있는지 고민해봐야겠다.
사실 아직도 400 과 404 에 대해 헷갈린다.
주로 400을 썼는데, 404가 익숙하다보니 자꾸 404가 더 적합하지 않을까 라는 생각이 들었다.
이 부분에 대해서는 꼭 피드백 받아보고싶다. -
온고지신의 시간이었다.
마감기한이 있어서 오랜만에 시간가는줄 모르고 코딩했던 것 같다.
과제 내용도 몇번 구현해본 경험이 있어서 잘 해낼 수 있을거라는 생각이 있었다.
더 발전하기 위해 코드칠 때마다 해당 코드와 관련된 개념과 문서들을 한번씩 더 확인했다.
짜임새 좋은 API 를 기준으로 직접 스키마도 설계해보고, 더 자세하게 API 문서를 작성해보면서 성장할 수 있던 시간이었다.
🌈 피드백
테마를 변경하는 부분에서 데이터가 많을경우 서버에 무리를 준다는 피드백을 받았다.
실제로 구현을 하는 것은 기본이고, 실제로 사용할 수 있는지도 판단해야겠다.
