[springboot / 게시판 API] API design v0.2

Goal 

1. 요구사항에 부합하는 API desgin을 해보자

 API desgin란? 

1. 심플하고 직관적으로 만들기

REST API를 URL만 보고도, 직관적으로 이해할 수 있어야 한다

/boards

/boards/1234

 

2. 동사보다 명사 사용하기 ( http method를 사용해서 구분)

행위를 URL에 사용하지 않기 ex. getBoardList, registBoard

리소스	POST	GET	PUT	DELETE
	create	read	update	delete
/board	새로운 board 등록	boards 목록을 리턴	board 정보를 업데이트	board 정보를 삭제

 

3.단어를 hyphen(-)으로 구분하기 (underscores _ , camel 표기법 x) 

 ex. example.com/boardUser-> example.com/board-user

 

4.컬렉션은 복수표현 (s 붙히기)

ex. 1. 게시글 목록 조회 get -> boards , 2.게시글 조회 get-> board

 

5. 소문자로 작성하기

 

REST API 디자인 가이드

 

 

요구사항 및 db설계

[springboot / 게시판 API] DB 설계 v0.5 - ERD 작성

[springboot / 게시판 API] 개발환경 및 요구사항 정의

 

 

그럼 디자인 한 일부를 살펴보자

1차 API design 

소분류	http	uri
회원 권한 등록 기능	post	/authority
회원 권한 목록 조회 기능	get	/authoritys
회원 등록 기능	post	/user
회원 조회 기능	get	/user/{user-id}
로그인 기능	post	/login
게시판 분류 등록 기능	post	/board
게시판 분류 목록 조회 기능	get	/boards
게시글 목록 조회	get	/board/{board-id}/posts
1. 게시글 상세 조회 2. 게시글 읽기 수 조회 3. 게시글 작성 시간 노출 4. 게시글에 작성된 댓글 수 조회	get	/board/{board-id}/post
게시글 작성 기능	post	/post/{board-id}
게시글 수정 기능	put	/post/{post-id}
게시글 삭제 기능	put or delete?	put으로 할 경후 수정 api와 이름 중복 or /post/{post-id}
게시글 읽기 수 수정 기능	put	/post/{post-id}/view-cnt
게시글 댓글 수 조회	get	/post/{post-id}/replys-cnt
게시물 댓글 목록 조회	get	/post/{post-id}/replys
게시물 댓글 작성 기능	post	/post/{post-id}/reply
게시글 댓글 수정 기능	put	/post/{post-id}/reply
게시글 댓글 삭제 기능	delete	/post/{post-id}/reply/{reply-id}

궁금한 점 & 피드백

1. 로그인은 명사로 표현이 안됨
   • restful api design이 가진 한계. 어쩔 수 없음. 예로, 좋아요를 하는 행위는 명사로 표현할 수 없으므로 위와 같이 해도 됨
2. 게시글 삭제의 경우 물리삭제가 아닌 삭제여부로 관리할 때 update의 개념이 아닌가? 하지만 put으로 하면 수정과 api 중복이된다
   • 삭제라는 키워드를 사용할 뿐, 소프트 딜리트 인지 하드 딜리트 인지가 중요한게 아니라 하지만 행위에 기반하기 때문에 delete로 하는 것이 맞다
3. 게시글 작성 같은 경우, 게시판 분류에 따라 다르니 분류id를 뒤에 두고, post - /post/{board-id}도 해도 되는가?
   • 지금 위의 디자인에서는 계층형을 알 수 없다. a라는 게시판 아래 b라는 게시물이 있는 경우 url 보고 유추 불가함. 정답은 없지만 설계에서 가장 중요한 것은 누구나 문서를 보고 유추할 수 있어야 하므로, /board/{board-id}/post라고 하는 것을 권장한다.
   • 또한 실제 요구사항에는 권한에 따른 게시판 접근을 위해 게시판 세팅 등록만 있을 지언정, api는 crud가 모두 존재 해야함.
   • 댓글은 post-id를 가지고 있어서 /board/{board-id}가 필요없을 것 같지만, 최대한 비슷하게 만들어주는 것이 좋다.
   • 또한, 회원이 접근할 수있는 게시판의 댓글을 로그인 하지 않은 상태에서 가져오려고 하는 경우는 어떻게 할 것인가?
     • 나 : 일단 로그인을 안했기 때문에, 게시판 자체가 노출이 되지 않을 것이다.
     • 멘토님 : 그것은 프론트엔드 관점이다. api서버도 웹이기 때문에 url호출하는 것을 막기 위해서는 그런 것들을 고려해야하는데, 댓글 api에  /board/{board-id}가 없다면 해당 post-id로 게시판세팅을 재조회 해서 권한을 확인해야하는데 그러면 오퍼레이션이 추가되므로 효율적이지 못하다. 그렇기 때문에 계층구조로 만들어 주어 로그인정보를 넘겨주어 체크해서 권한 처리를 할 수 있다. 

2차 API design 

소분류	http	uri
회원 권한 등록 기능	post	/authority
회원 권한 목록 조회 기능	get	/authoritys
회원 권한 조회 기능	get	/authority/{auth-id}
회원 권한 수정 기능	post	/authority/{auth-id}
회원 권한 삭제 기능	delete	/authority/{auth-id}
회원 등록 기능	post	/user
회원 중복 확인 기능	post	/user/check-duplicate/{login-id}
회원 조회 기능	get	/user/{user-id}
회원 수정 기능	put	/user/{user-id}
회원 삭제 기능	delete	/user/{user-id}
로그인 기능	post	/login
게시판 분류 등록 기능	post	/board
게시판 분류 목록 조회 기능	get	/boards
게시글 목록 조회	get	/board/{board-id}/posts
1. 게시글 상세 조회 2. 게시글 읽기 수 조회 3. 게시글 작성 시간 노출 4. 게시글에 작성된 댓글 수 조회	get	/board/{board-id}/post
게시글 작성 기능	post	/board/{board-id}/post
게시글 수정 기능	put	/board/{board-id}/post/{post-id}
게시글 삭제 기능	delete	/board/{board-id}/post/{post-id}
게시글 읽기 수 수정 기능	put	/board/{board-id}/post/{post-id}/view-cnt
게시글 댓글 수 수정 기능	put	/board/{board-id}/post/{post-id}/replys-cnt
게시물 댓글 목록 조회	get	/board/{board-id}/post/{post-id}/replys
게시물 댓글 작성 기능	post	/board/{board-id}/post/{post-id}/reply
게시글 댓글 수정 기능	put	/board/{board-id}/post/{post-id}/reply
게시글 댓글 삭제 기능	delete	/board/{board-id}/post/{post-id}/reply/{reply-id}

피드백 반영

1. crud가 기본적으로 되도록, 필요 메서드를 추가하였고

2. 삭제는 delete로 변경

3. 계층형이 되도록 /board/{board-id}를 추가 

4. 회원 중복 기능 추가