POST

1. 기본 예시

POST 메소드로 "뽀로로"라는 이름을 가진 학생을 생성하기 위해 요청

{
  “name”: “뽀로로”,
  “grade”: 1
}

고유 구분값인 id가 1로 설정되어, "뽀로로"라는 학생이 생성된다

{
  “id”: 1,
  “name”: “뽀로로”,
  “grade”: 1
}

2. 적용 예시

POST 메서드로 "뽀로로" 학생을 생성해달라고 2번 요청

{
   “name”: “뽀로로”,
   “grade”: 1
}

요청 결과

{
	“id”: 1,
  	“name”: “뽀로로”,
  	“grade”: 1
},
{
	“id”: 2,
    “name”: “뽀로로”,
    “grade”: 1
}

PUT

1. 기본 예시

POST 를 통해 생성한 데이터

{
  “name”: “뽀로로”,
  “grade”: 1
}

이를 PUT 을 통해 수정

{
  “grade”: 2
}

수정한 결과

{
  “id”: 1,
  “name”: “뽀로로”,
  “grade”: 2
}

단, PUT은 리소스에 대한 수정이므로, 특정 리소스를 구분하는 id값을 넣어줘야 한다.

2. 적용 예시

POST 를 통해 생성한 데이터

{
  “name”: “뽀로로”,
  “grade”: 1
}

PUT 메서드로 수정하도록 두 번 요청

{
  “name”: ”에디”
  “grade”: 2
}

수정 결과

{
	“id”: ”3”,
    “name”: “에디”,
    “grade”: 2
}

몇 번을 보내도 동일한 응답이 온다.
(id 값 3을 가진 리소스는 없었으므로, 최소 한번은 생성되고 그 후에는 생성되지 않음)

---

결론

POST

• 리소스의 생성을 담당

• 요청 시 마다, 새로운 리소스가 생성된다.

• "멱등하지 않다."

PUT

• 리소스의 생성/수정을 담당

• 요청 시 마다, 같은 리소스를 반환한다.

• "멱등하다."

멱등 (Idempotent)
"멱등하지 않다" = 여러 번의 재시도에 대한 모든 결과값이 동일하지 않다.

---

참고: RESTful한 세계에서의 POST와 PUT의 차이, 거기에 PATCH까지
참고: RESTful API POST와 PUT의 차이