스프링 카페를 할 때 처음 만든 테이블 도식도이다. 이에 대해 리뷰를 받은 것들을 확인해보자.
comment 테이블을 보면 불필요하게 writer_id, writer_name 모두가 외래키 제약 조건이 걸려 있다. 외래키는 말 그대로 key이기 때문에 writer를 식별할 수 있는 하나의 값만 존재하면 된다.
이번에 칼럼명을 정할 때 name같은 경우는 예약어로 정해져있어서 다른 방식으로 표현하려고 했는데, 예약어로 정해져 있는 경우는 실무에서 어떻게 처리하는지 궁금합니다!
이렇게 pr에 질문을 올렸을 때 리뷰어분은
예약어 같은 경우는 member의 name 이라면 member_name와 같은 식으로 네이밍하는 편인것 같습니다.
이렇게 답변을 주었다.
외래키와 관련해서 다시 테이블을 분석해보니, issue에 writer_name과 writer_id가 외래키로 존재했다. 아마도 작성자의 이름과 id를 모두 issue테이블에 넣어주고자 하는 의도에서 그랬던 거 같다.
지금 생각해보니 이런 경우에는 그냥 writer를 식별할 수 있는 외래키를 갖고 있고, join을 통해서 데이터를 가져오면 될듯하다.
수정은 POST로 할지 PUT으로 할지?
처음에 PR을 올릴 때 수정을 위한 메서드를 POST로 할지 PUT으로 할지 감을 잡지 못했다. 이에 산토리(리뷰어)는 데이터 생성은 POST로 수정은 PUT을 쓴다고 하면서 API의 멱등성을 고려하라는 말과 함꼐 레퍼런스를 주었다.
이 글을 보면,
멱등성이란 연산을 여러번 적용해도 결과가 달라지지 않는 성질을 뜻한다고 한다.
동일한 요청을 한번 보내는 것과 여러번 연속해서 보내는 것이 같은 효과를 가지고, 서버의 상태도 동일하게 남았을 때 해당 HTTP 요청이 멱등성을 가진다고 할 수 있는 것이다. (이는 응답 상태 코드가 아니라, 서버의 상태를 말한다)
GET, PUT, DELETE는 멱등성을 갖고 POST와 PATCH는 멱등성을 가지면 안 된다.
POST
서버로 데이터를 전송하는 메서드다. 일반적으로 볼 때 새로운 자원을 생성하기에, 같은 요청을 여러 번 보내면 매번 새로운 자원이 생겨나야 한다. 서버의 상태가 변하기 때문에 멱등성을 갖지 않는다.
PUT
PUT는 새로운 리소스를 생성하거나 대상 리소스를 나타내는 데이터를 덮어 쓴다. PUT은 만약 해당 자원이 이미 있다면 데이터만 덮어쓰기 한다. 요청을 한번하든 여러번 하든 서버의 상태는 같다.
PATCH
PATCH는 리소스의 부분적인 수정에 사용된다. 그런데 멱등성을 갖지 않는다.
기존의 리소스
{
id: 1,
name: "김철수",
age: 15
}여기에
PUT /users/1
{
age: 20
}이걸 보낸다고 해보자.
변경된 리소스는 다음과 같다.
{
id: 1,
name: NULL,
age: 20
}
기존의 리소스
{
id: 1,
name: "김철수",
age: 15
}PATCH /users/1
{
age: {
type: $inc,
value: 1
}
}변경된 리소스
{
id: 1,
name: "김철수",
age: 16
}
PATCH는 HTTP 스펙상 구현 방법에 제한이 없다. 그렇기때문에 요청 Body에 꼭 덮어쓸 데이터가 있을 필요가 없다. 위 예시처럼 덮어쓸 데이터가 아닌 동작을 지정해줄 수 있는 것이다.
위 예시의 경우 동일한 요청을 여러번 보내면, 매 요청마다 age가 1씩 증가한다. 즉, 멱등성을 가지지 않는 것이다.
코드 리뷰
1)git 레포에는 .idea 폴더가 들어가지 않는 게 좋다.
.idea 폴더는 인텔리제이의 ide 옵션을 저장하는 폴더로, 옵션이 작업자의 컴퓨터 환경에 맞춰서 변경된다고 한다. 다른 작업자가 소스를 받을 때 영향을 받지 않도록 하기 위해서 .gitignore에 추가해야 한다는 뜻이다.
