HTTP - 메서드

• URI설계에 가장 중요한것은 리소스 식별이다.
• URI에 등록/조회/수정/삭제의 요소를 제외하고, 리소스만 식별하면 된다.
• 메서드는 리소스와 해당 리소스를 대상으로 하는 행위를 분리하도록 한다.
• 리소스는 명사, 행위는 동사

메서드의 종류

• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제
• HEAD: GET과 동일하지만, 메시지 부분을 제외하고, 상태줄과 헤더만 반환
• OPTION: 대상 리소스에 대한 통신 가능 옵션을 주로 설명
• CONNECT: 대상자원으로 식별되는 서버에 대한 터널을 설정

GET

• 리소스를 조회
• 조회시 서버에 전달하고 싶은 데이터는 request-line의 query를 통해서 전달한다.
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 권장하지 않는다.

1. 클라이언트가 서버로 메시지 전달
2. 내부 데이터베이스 조회
3. 데이터 생성
4. 응답메시지 생성 및 전달

POST

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달, 서버는 요청데이터 처리
• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
• 주로 신규 리소스 등록, 프로세스 처리에 사용
• POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야함.
• 컨트롤 URI로 설계하기도 한다. ex) POST /orders/{orderId}/start-delivery

1. 클라이언트가 서버로 메시지 전달
2. 서버에서 신규 리소스 생성
3. 신규 리소스 식별자 생성
4. 응답메시지 전달

ex ) HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공

게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사항 기사 그룹에 메시지 게시

 

=> 데이터를 처리하는 행위에 대해 자유로운 편이며, 다른 메서드로 처리하기 애매한 경우에 POST를 사용한다.

PUT

• 리소스가 있으면 대체, 없으면 생성
• 클라이언트가 리소스 위치(식별자)를 알고 URI 지정

!주의할점!
기존의 리소스를 완전히 대체한다.
{
  "userName": "young",
  "age":20
}

↓ POST "age": 50 

{
  "age":50
}

• 기존의 리소스를 유지하고 일부만 변경하려면 PATCH를 사용한다.

DELETE

• 리소스 제거

---

메서드의 속성

안전 (safe Methods)

• 호출해도 리소스를 변경하지 않는다. (GET같은 경우)

멱등 (Idempotent Methods)

• f(f(x)) = f(x)
• 한번 호출하든, 두번호출하든, 100번 호출하든 결과가 똑같다.

멱등한 메소드

• GET: 한번 조회하든, 두번 조회하든 같은 결과가 조회된다.
• PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
• DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
• POST: 멱등이 아니다. 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.

활용

• 자동 복구 매커니즘
• 서버가 TIMEOUT등으로 정상 응답을 못주었을때, 클라이언트가 같은 요청을 다시 해도 되는지 판단하는 근거

Q.재요청 중간에 다른 리소스를 변경해버리면?

A. 멱등은 외부 요인으로 중간에 리소스가 변경되는것 까지는 고려하지 않는다.

캐시가능 (Cacheable Methods)

응답결과 리소스를 캐시해서 사용해도 되는가?

GET, HEAD, POST, PATCH 캐시 가능

실제로는 GET, HEAD정도만 캐시로 사용

---

참고 강의 : https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC