API 엔드포인트 설계 시 질문입니다.

Question

게시판의 게시글과 댓글을 예시로 들겠습니다.댓글의 삭제 요청에 대한 경우, DELETE: /posts/{postId}/comments/{commentId} 위와 같은 방식으로 예시를 드는 경우가 많습니다.스프링 기반이라면 &#64;PathVariable로 {comment}를 받아서 처리할 것입니다.그런데 일반적으로 댓글 테이블은 게시글 테이블과 별개의 PK를 가집니다.즉, postId를 몰라도 commentId만 가지고도 comment 레코드를 식별 할 수 있는데위와 같은 엔드 포인트에서는 postId가 불필요하고, 낭비라고 생각이듭니다.물론 조회 시에는 아래와 같은 방식이 필요하기에GET: /posts/{postId}/comments엔드 포인트의 일관성[?]을 위해서라면 납득이 가긴 합니다.크게 신경 쓸 필요는 없는 부분일까요?추가로 어떤 사이트에서는 모든 API 요청을 POST로 통일해서 아래와 같이 쓰던데 이런 방식은 어떻게 생각하시는지 의견 듣고싶습니다.POST: /find/comments param &#61; { postId: 111 } POST: /delete/comment param &#61; { commentId: 123 }사소한 것 하나에도 오만 생각을 다하는 성격이라 궁금한 게 많네요. 친절히 답해주시는 오키 개발자님들 감사드립니다 (_ _)

으헝러헝헝 · Answer

한개의 게시판에서는 뭐 어차피 게시판 한개에 테이블 1개 댓글 테이블1개 정도 사용할테니,그럴 수 있다고 쳐도,성격이 다른 게시판들이 여러 개 있다고 생각하면1번 방법으로 하는 게 가독성이 더 있겠죠, 해당 URL에서 발생한 오류면 해당 uRL을 제어하는 컨트롤러 부분부터 오류를 확인할 수 있으니 저는 1번방법으로 합니다.2번의 경우에는 저도 잘은 모르지만, 예전에 restful api 작성방법이 없었을 당시 delete나 patch같은 메소드가 있지 않아서 생겼다고 들었었는데, 현재에도 그 방식을 고수하고 있는 이유가금융권이나 특정분야에서는 보안을 위해 get, post만 지원한다고 하더라고요. 그래서 그 방법을 사용하는 것 같습니다.

API 엔드포인트 설계 시 질문입니다.

1개의 답변

기술 목록