기능 돌아보기
1. 페이지 별로 들어갈 내용 정리에서 각 페이지 별 기능에 대해 정리했었는데, 이를 다시 정리하면서 어떤 api가 필요한지 파악해 보는 것이 우선이다.
Header
Header의 경우 페이지 링크가 대부분을 구성하고 있다. 상단바 검색 기능이 있는데 이 부분은 전체 검색 기능을 가진 api를 만들어 주어야 할 것 같다. 검색어를 querystring으로 넘겨주면 DB에서 해당 게시글을 가져와서 전체 검색 페이지에 보여 주면 된다.
- 검색 결과를 가져오는 api가 필요하다. 각 게시판별로 가져와야 하며, 게시판 당 최대 개수를 제한해야 한다.(아마 5개면 충분할 것 같다.)
Index
API가 필요할 만한 부분은 각 게시판에서 글을 받아 오는 부분이다. 글을 가져 오는 api를 만드는데, index page를 위한 api를 따로 만들어 주는 게 좋을 수 있겠다는 생각을 했다. 처음에는 posts와 같은 api를 쓰려 했는데, paging 설정도 그렇고 가져오는 데이터 개수도 달라서 index 전용 api를 하나 만들어 주는 게 더 나을 것 같다는 생각이 든다.
Posts
당연히 여기서는 게시글을 보여 주는 역할을 하는 api를 작성해야 한다. 그리고 querystring으로 정렬 기준과 page를 받아서 처리 해 주어야 한다. 게시판 내 검색도 필요한데, 결국 똑같이 게시글을 보여 주는 것은 변하지 않으므로 querystring으로 검색어와 검색 기준을 추가하면 될 것 같다.(querystring 내 정보가 4개인데, 좀 복잡할 것 같기는 하다.) 게시판 종류는 path variable을 이용해야 할듯?
Search_results
아까 Header에 나온 검색 결과 api를 사용하면 된다.
Post_detail
여기서는 세부 글의 내용을 보여 주는 api를 사용해야 한다. path variable을 이용하여 글 하나만 집어서 가져오면 된다. 이 api에는 해당 게시글에 딸린 댓글과 대댓글, user의 정보 등이 담겨 있으면 된다. 그리고 작성자인 경우, 글의 수정과 삭제를 위한 api 역시 만들어 주어야 한다. 또한 댓글을 쓰는 api와 댓글의 작성자일 시 댓글을 수정, 삭제하는 api도 필요하다.
Post_create
여기서는 제목, 내용, 이미지 등을 받아서 글을 작성하는 api를 쓰면 된다. 글의 수정 역시 이 페이지로 넘어간다.
Mypage
회원 정보를 가져오고, 수정, 삭제하는 api가 필요하다. 그리고 user가 쓴 댓글을 가져오는 api, 유저가 쓴 글을 가져오는 api, 유저가 좋아요 한 글을 가져오는 api를 따로 만드는 것이 좋을 것 같다. 셋을 한 번에 보내 주면 세 데이터에 해당하는 정렬, 검색을 따로 만들어야 해서 보기 좋게 깔끔하게 빼는게 나을 거 같음.
Lecture_board
게시판과 별 다를 게 없다. 강의들을 보여 주는 api가 필요하고, 게시글들처럼 paging과 최신순 정렬, 검색 기능을 포함해야 한다.
앞서 페이지 중 강의 업로드 페이지가 빠져 있는데, 따라서 강의 업로드를 위한 api 역시 필요하다는 것을 짚고 넘어가도록 하겠다.(사실 post랑 똑같은 table을 쓰고 동영상 링크를 넣는 방식을 쓸까 생각중이다.)
Lecture_detail
강의 내용을 보여주는 api가 필요하다. post와 비슷하니 일단 넘어가도록 하겠다. 강의는 유튜브에 올린 걸 틀어 주는 방식으로 서비스할 예정이다.
이거 말고 기본적인 User 생성(Join), 닉네임 중복 체크 api, ID 중복 체크 api, 로그인 api가 필요하다. 그리고 아이디 찾기와 비밀번호 찾기 api도 필요하다.(pw의 경우 인증 포함하기)
또한 사이트에서 페이지 이동 시 로그인이 만료되었다면 다시 로그인 페이지로 이동하게끔 해 줘야 하는데, 그 말은 로그인이 되었는지 체크하는 api가 필요하다는 이야기이다. refresh 관련 api도 만들어 둬야 한다.(자동 로그인 체크가 안 되어 있다면 로그아웃되면서 Header가 바뀌고 로그인되며, 자동 로그인을 하도록 되어 있다면 자동으로 refresh해준다.)
Method, URI 설정하기
URI를 설정하기 전에 고민이 생겼다. 검색이나 로그인 등 resource라기보다는 action에 가까운 행동들도 존재하는데 URI를 RESTful하게 짜기 위해서는 URI에 행위에 대한 정보가 아닌 resource에 대한 정보가 들어가야 하기 때문이었다. 예를 들어 전체 검색 api를 GET /search 로 설정한다면 이는 REST 원칙에 명백히 위배된다. 로그인 api를 POST /user/login과 같이 설정하는 것 역시 마찬가지 문제를 지닌다. 검색을 해보니 나와 비슷한 고민을 겪었던 분들도 있었다.
앞선 글에서 HATEOAS, self-desciptive를 제외한 다른 REST 원칙들은 지키는 쪽으로 URI를 짜기로 결정했으므로, 최대한 이를 지키고 싶었다. 최대한 resource명만 활용하여 짜도록 uri를 설계해 보았다.
GET /user/id/{id}: ID 중복체크 API. Signup 시 사용할 예정이다. 해당 ID가 존재하는지 판별해야 하므로 /user 뒤에 id를 추가적으로 붙였다. 아이디 찾기에서도 이 api를 그대로 사용할 수 있다.GET /user/nickname/{nickname}: ID 와 마찬가지로 nickname 중복체크 API를 구성한다.POST /user: 회원가입 API로, 아이디, password, 닉네임, 이메일을 받아서 User 데이터를 추가한다.GET /user/{id}: 마이페이지에서 로그인한 회원 정보를 가져오는 데 쓰는 api이다. 허용된 유저만 가져올 수 있도록 인증 데이터를 참조해야 한다. 나머지 GET, PATCH, DELETE method도 마찬가지.GET /user/posts/{id}: 유저가 쓴 글을 가져오는 api이다.GET /user/comments/{id}: 유저가 쓴 댓글을 가져오는 api이다.GET /user/likes/{id}: 유저가 추천한 글을 가져오는 api이다.PATCH /user/{id}: 유저 정보를 수정하는 api이다.(이메일, 닉네임, 비밀번호)DELETE /user/{id}: 유저를 삭제하는 api이다.POST /user/session: 로그인 API인데, 사실 Django에서는 로그인 기능을 제공하고 있기 때문에 이를 사용하려고 생각 중이다. 처음에는 auth로 하려 했는데 인증 역시 session이라는 resource를 사용하는 행위이므로 session으로 바꾸었다.GET /user/session: 접근할 때 로그인이 필요한 페이지에 접속하기 위해(post_create같은) frontend에서 로그인 여부를 확인하는 작업이 필요하다.이를 위해 localstorage나 sessionstorage를 활용하는 방법도 생각해 보았지만 사용자가 이를 변경할 수 있기 때문에 완벽하다고는 볼 수 없다. 따라서 로그인이 필요한 페이지 접속 시 user의 auth 정보를 확인하는 api를 만들어 줄 예정이다.(나중에 코드 구현에 따라 필요 없어질 수도 있을 것 같다.)POST /user/email-auth: 비밀번호 바꾸기에서 선행되어야 할 이메일 인증을 하는 api이다. 인증을 할 때 DB 내에서 authenticated 여부를 수정해 주어야 할 것 같아서 GET이 아닌 POST로 Method를 설정했다. REST를 지키려 했는데 이메일 인증을 resource만으로 표현하는 방법이 떠오르지 않아 찜찜하다.
여기까지가 일단 User 관련 api이다. 이제 user를 제외한 기능적인 부분의 api를 간략하게 설명한다.
GET /main: 메인 페이지index를 보여 주는 데 필요한 게시글들을 보내 주는 api이다.GET /all: 전체 검색 시 글들을 보여 주는 api이다. querystring으로 검색어를 받도록 한다.GET /posts/{category}: 게시판 단위로 글들을 보여 주는 api이다. querystring으로 자체 검색어와 검색 기준, 그리고 정렬 기준을 정해 주고, page도 넣어 주어야 한다. category에는 게시판 이름이 들어간다.(과목, 게시판 구분을 하나로 묶는다. 국어 자료 게시판, 수학 질문 게시판과 같은 식으로..)GET /posts/post/{id}: 각 글의 세부 내용을 보여 주는 api이다. 여기에 글의 댓글들까지 전부 딸려 오도록 할 예정이다.POST /posts/post: 새로운 글을 작성하는 api이다.PUT /posts/post/{id}: 글의 세부 내용을 수정하는 api이다. form으로 데이터를 수정하는 것을 고려해 볼 때, 전체 데이터를 덮어쓰는 형식이 될 것 같아서 일단 PATCH 대신 PUT을 씀.DELETE /posts/post/{id}: id에 해당하는 글을 삭제하는 api이다.POST /posts/{post_id}/comment: post_id에 해당하는 글에 댓글을 다는 api이다.PUT /posts/{post_id}/comment: id에 해당하는 댓글을 수정하는 api이다.DELETE /posts/{post_id}/comment: id에 해당하는 댓글을 삭제하는 api이다.POST /posts/{post_id}/likes: id에 해당하는 걸에 추천을 하는 api이다. toggle로 작동하게 할 예정.POST /posts/{post_id}/likes/comment/{comment_id}: post, comment id에 해당하는 comment에 추천을 하는 api이다. toggle로 작동한다.
나머지는 lecture 관련 api들인데 이는 아직 확정된 것이 없어서 확정되면 마저 쓸 예정이다.
자료를 찾으면서 heroku API를 디자인하면서 뽑은 API 디자인 원칙에 대한 글을 찾았는데, 참고해 보면 좋을 것 같아서 여기 링크를 남긴다.
사실 설계 단계에서 response와 request body를 최대한 짜 보려고 했는데 코드를 구현하면서 아마 무조건 수정이 필요할 것 같기도 했고 아직 DB schema 관련해서도 나온 게 없어서 지금 당장 정하기 쉽지 않았다. 또한 auth 관련 코드들은 어떤 데이터가 필요한지 구현 전에 감이 잘 안 와서 일단 이 정도로 정리하려고 한다.
다음 목표
이제 api를 어떤 식으로 짤 것인지 대략적인 구상까지는 했다. 데이터베이스를 어떤 것을 사용할 것인지, RDBMS를 쓸 것이면 Table 간 relation은 어떻게 구성할 것인지, key는 어떻게 할 지 등의 DB 관련한 의사 결정을 해야 할 차례다. 코드를 빨리 짜고 싶은 마음이 있는데 그 전에 의사 결정을 할 요소들이 참 많은 것 같다는 생각이 든다.
