ㅠㅠ.. 이제 17번째 포스팅을 적고 있군요
코로나 감염으로 한 주 건너뛰기는 했지만,
지난 스터디에 나왔던 내용들 정리와 구현 내용에 대해서 공유해보려고 합니다~!
🎉 Done
1. REST에 대한 고찰
1-1. 리마인드
임시 저장에 대한 API 네이밍을 어떻게 가져가면 좋을까?
지난 시간에 임시 저장에 대한 API 네이밍을 어떻게 가져가면 좋을지에 대해 이야기했었습니다.
그래서 REST 관련된 개념들을 학습했는데, 이번 주제와 관련 있는 거 위주로 소개를 드리겠습니다.
1-2. REST API의 목적
REST API의 목적은 이해하기 쉽고 사용하기 쉬운 API를 제작하는데에 있다.
성능 향상과 같은 정답이 정해진 문제가 아니기 때문에 동료들과 합의하에 일관성있는 룰로 정해서 가독성을 높이는 것이 포인트이다.
그래서 정해진 정답은 없지만 이렇게 해보니 좋더라~ 라는 예시 케이스들을 많이 소개하고 있어서
공유하고 넘어가려고 합니다!
1-3. REST에서 정의하는 자원의 종류
API라는 것은 결국 서버의 자원에 접근하는 행위.
그래서 서버가 가진 리소스의 성격에 따라 주로 네 가지로 분류하는 경우가 많았습니다.
분류를 해놓아야 좀 더 일관성있는 네이밍 부여가 가능해지기 때문이죠!
1) Document
- 파일 하나
- 객체 인스턴스
- 데이터베이스 row
2) Collection
- Document의 집합
- DB 스키마
- 리소스 디렉토리
3) Store
- 클라이언트가 관리하는 자원 저장소
- Document와 다른 점은 관리 주체가 client인 것이 다름
4) Controller
- 위 세 가지로 해결하기 어려운 추가 프로세스 실행
- 단, HTTP method로 표현가능한 경우에는 별도의 동사를 붙이지 않는다
- REST는 기본적으로 명사형을 사용하라고 하지만 contoller의 경우에는 예외적으로 동사 사용
참고 자료
1) REST 관련 개념 정리
2) REST 네이밍 관련 링크
3) REST API 정리
1-4. 실제 적용
포스팅 작성 중 임시 저장, 수정하기의 경우 uri를 어떻게 정하는 것이 좋을까?
리소스의 분류
- 포스팅 작성의 경우 document POST
- 수정하기의 경우 document PUT
- 임시 저장의 경우 contoller
- 단순 포스팅 작성이라면 POST로 했겠지만 원본 post를 업데이트하는 행위는 아니고 별도의 TEMP_POST 테이블에 데이터를 추가하는 것이기때문에 별도의 작업이라고 생각함
최종 의견
- 포스팅 작성 :
POST ('/write') - 수정하기 :
PUT ('/write') - 임시 저장 :
POST ('/write/tempsave')
코드 히스토리
- 원본
- 1차 수정
- 마지막 수정
2. 임시저장 클라이언트 구현
2-1. 임시저장 life-cycle
임시 저장된 포스트는 오로지 출간하기를 통해서만 삭제된다.
2-2. Client 로직
클라이언트에서는 /write/tempsave API를 30초마다 호출하면서 현재 PostData를 넘겨준다.
- useEffect에서 interval 함수 등록
2-3. tempsave API 플로우 차트
2-4. write API 추가 구현
임시 저장 시나리오를 고려하여 마지막에 임시 저장된 포스트를 삭제하는 로직을 추가하였습니다.
2-5. 서버 구현
- API 구현
makeTempSaveQuery 함수 내부에서 아까의 플로우 차트에 따른 query 생성
📝 To-Do
1. 출간하기 후 포스팅 view 페이지 연결
2. 기존 포스팅에서 수정하기 클릭 시
3. Toolbar 설계
