HTTP 메서드

1. HTTP 메서드란?

클라이언트가  사용자 요청의 목적이나 종류를 웹 서버에게 알리는 방법이다.

 

2. HTTP 메서드 종류

• GET: 리소스 조회
• POST: 요청한 데이터를 처리. 여러 방면에서 사용 가능하며 주로 등록에 사용
• PUT: 해당 리소스가 없으면 생성하고 있으면 리소스를 완전히 대체
• PATCH: 리소스를 부분적으로 변경
• DELETE: 리소스를 삭제

 

---

 

1. GET

• 서버에 전달할 데이터는 Query Prameter, Query String을 통해서 전달한다.
• Message Body를 통해서 데이터를 전달할 수도 있지만 지원하지 않는 서버가 많아서 권장하지 않는다.

 

2. POST

• Message Body를 통해 서버로 요청 데이터를 전달한다.
• 서버에서는 받은 데이터를 처리하는 여러 모든 기능을 수행할 수 있다.
• 주로 신규 리소스 등록, 프로세스 처리에 사용한다.
• 여러 기능을 수행할 수 있다는 말은 즉 URI에 POST 요청이 들어오면 요청 데이터를 어떻게 처리할지는 리소스마다 따로 내가 정해야 한다는 것이다.
• POST는 클라이언트가 등록될 리소스의 URI 위치를 알지 못하고 POST 요청하면 서버가 새로 등록된 리소스 URI를 생성해서 알려준다.
  • 컬렉션(Collection): 서버가 관리하는 리소스 디렉터리이며, 서버가 리소스의 URI를 생성하고 관리한다. 만약에 /members의 post 메서드가 있다고 하면 /members가 컬렉션이 된다. 

 

• 1. 새 리소스를 생성
• 2. 요청 데이터 처리
  • 단순히 데이터를 생성 또는 변경하는게 아니라 프로세스를 처리해야 하는 경우
    • 예시) 주문에서 결제완료 -> 배달 시작처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
  • 여기서 POST의 결과는 항상 새로운 리소스가 생성되는 게 아니란 것을 알 수 있다.
• 3. 다른 메서드로 처리하기 애매한 경우에
  • Message Body를 통해 조회에 필요한 데이터를 넘기고 싶은데 GET 메서드는 Message Body를 지원하지 않는 서버가 있을 수 있으므로 POST를 사용할 수도 있다.

 

참고) 컨트롤 URI

이전 포스팅에서 URI 설계를 할 때 행위는 우선 배제하고 리소스만 식별하여 설계해야 한다고 했는데 이게 항상 적용할 수 있는 건 아니다.

위의 결제완료에서 배달 시작으로 변경하는 POST 요청에서는 URI를 /orders/{orderId}/start-delivery와 같이 행위를 URI에 추가하여 컨트롤 URI로 설계할 수도 있다. 

또는 HTML Form은 GET, POST만 지원하므로 제약이 생길 수 밖에 없다. 이런 제약을 해결하기 위해 동사로 된 리소스 경로를 사용하는데 예시로 POST: /members/{id}/delete 처럼 어쩔수 없이 delete라는 동사를 URI에 추가한다. 

 

3. PUT

• 리소스가 있으면 완전히 대체하고 없으면 새로 생성한다.
• POST는 클라이언트가 리소스 위치를 알지 못하고 서버가 새로 등록된 리소스의 URI를 생성해서 위치를 반환해주는데 PUT은 /members/100처럼 클라이언트가 리소스 위치를 이미 알고 URI를 지정한다.

 

4. PATCH

• 리소스를 부분적으로 변경하고 싶을 때 사용한다.
• 지원하지 않는 서버가 존재할 수도 있어서 확인하고 사용하던지 POST로 대체한다.

 

5. DELETE

• 리소스를 제거할 때 사용한다.

---

 

HTTP 메서드의 속성

• 안전 (Safe Methods)
• 멱등 (Idempotent Methods)
• 캐시 가능 (Chacheable Methods)

 

1. 안전

• 호출해도 리소스를 변경하지 않는다.
• GET은 안전하지만 그걸 제외한 POST, PUT, PATCH, DELETE는 안전하지 않다.
• 안전은 해당 리소스가 변경되는지만 고려한다.

 

2. 멱등 

• 동일한 사용자가 어떠한 요청을 한 번 호출하든 몇 번을 호출하든 결과가 동일하다.
• 외부 요인으로 인해 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.
• GET, DELETE는 당연히 멱등할 것이고 PUT은 왜 멱등하냐면 결과를 대체하는 작업을 여러번 반복해도 최종 결과는 동일하기 때문이다. POST는 여러번 호출할 경우 예를 들어 같은 주문이 여러번 중복해서 발생할 수 있으므로 멱등이 아니다.
• 정리하자면
  • GET, PUT, DELETE : 멱등O
  • POST: 멱등X
• 어디서 활용할 수 있나?
  • 자동 복구 매커니즘
  • 서버가 정상 응답을 못주었을 때, 클라이언트가 확실히 하려고 같은 요청을 다시 하려고 할 때 해도 되는지 판단 근거가 됨

3. 캐시 가능

• 응답 결과 리소스를 캐시해서 사용한다.
• GET, HEAD, POST, PATCH는 캐시가 가능하다.
• 하지만, 캐시 하려면 바디 내용까지 캐시 키로 고려해야 하는데 POST, PATCH 같은 경우는 구현이 쉽지 않다.
• 따라서, 실제로는 GET, HEAD 만 캐시로 사용한다. GET은 URI만 잡고 캐시하면 되기 때문

 

---

참고 URI 설계 개념

1. 문서(document)

• 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
• EX) /members/100, /files/ex.jpg

2. 컬렉션(collection)

• 서버가 관리하는 리소스 디렉터리
• 서버가 리소스의 URI를 생성하고 관리
• EX) /members

3. 스토어(store)

• 클라이언트가 관리하는 자원 저장소
• 클라이언트가 리소스의 URI를 알고 관리
• EX) /files

4. 컨트롤러(controller), 컨트롤 URI

• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동사를 URI에 직접 사용
• EX) /members/{id}/delete

참고: https://restfulapi.net/resource-naming