PUT, POST 또는 PATCH?

CRUD의 조작을 REST로 표현하면 일대일로 대응하고 있지 않다는 것을 깨닫습니다. R은 GET, D는 DELETE라고 생각해도 좋을 것 같습니다만, C와 U는 PUT, POST, PATCH의 3개의 선택사항이 있어, API를 설계하고 있다고 헤매습니다. 정리하기 위해 정리해 두고 싶습니다.

아래의 자료를 참고로 했습니다.

http - PUT vs POST in REST - Stack Overflow

When to use PUT or POST | - The RESTful cookbook

GitHub API v3

기본 사고 방식

PUT : 리소스 만들기, 리소스 바꾸기

POST: 리소스 만들기

PATCH : 리소스의 부분 대체

PUT

PUT는 POST와 달리 자원 이름을 지정하여 작성하거나 갱신하는 메소드입니다. PUT /articles/3421는 새로 만들거나 업데이트할 수 있습니다. PUT는 idempotent 조작입니다. 여러 번 해도 같은 결과가 되는 처리입니다. 예를 들어, Qiita의 기사를 재고하는 작업은 여러 번 해도 스톡 상태에 변화가 없기 때문에 idempotent입니다. MySQL이라면 REPLACE에 가깝습니까?

POST

POST /articles 그러면 리소스 이름이 서버 측에서 할당되고 /articles/3421 등이 가능합니다. MySQL에서 말하면 auto_increment가 붙어 있는 컬럼의 값을 지정하지 않는다 INSERT에 가까운 이미지입니다. POST는 idempotent가 아닌 처리가 됩니다.

패치

자원을 부분 갱신하는 메소드입니다. 예를 들어 기사 제목만 업데이트하거나 기사 본문만 업데이트하는 인터페이스를 제공하는 데 사용됩니다.

조작으로 POST 및 PUT

리소스 읽기와 쓰기만으로 API가 완결되면 위의 이해로 만들 수 있을 것 같습니다만, API에 따라서는 리소스에 액션이 있는 경우가 있습니다.

예를 들어 GitHub에서 말하면 저장소에 별표를 붙이거나 분기를 병합 할 수 있습니다. 이 경우 역시 idempotent인지 판단 기준이 될 것 같습니다.

idempotent 조작 GitHub의 스타를 붙이는 API은 PUT /user/starred/:owner/:repo입니다. 반면 브랜치는 병합할 작업 POST /repos/:owner/:repo/merges입니다.

덧붙여서, DELETE도 조작으로서는 idempotent입니다만, 자원이 없어지고 있는 경우, 2번째의 DELETE
404가 되는 것이 보통인 것 같습니다. http - Is REST DELETE really idempotent? - Stack Overflow

끝까지 읽어 주셔서 감사합니다. Twitter에서는, Qiita에 쓰지 않는 기술 재료 등도 트윗하고 있으므로, 좋으면 팔로우 부탁합니다 → Twitter@suin