HTTP 메서드 정리

HTTP 메서드의 종류

주로 자주 사용되는 메서드는 GET, POST, PUT, PATCH, DELETE가 있다.

GET

리소스를 조회할 때 사용. 쿼리 파라미터를 통해 서버에 데이터 전달. 메시지 바디를 통해서도 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많음.

POST

메시지 바디를 통해 서버로 요청 데이터를 전달한다. 서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다. 주로 전달된 데이터를 신규 리소스 등록, 요청 데이터 처리, 다른 메서드로 처리하기 애매한 경우에 사용한다. 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리해야 되는지 정해진 것이 없기 때문에, 리소스마다 어떻게 처리할지 따로 정해야 한다. POST의 결과로 새로운 리소스가 생성되지 않을 수도 있다. 신규 리소스 등록 시 클라이언트는 등록될 리소스의 URI를 모르고, 서버가 새로 등록된 리소스 URI를 생성해준다. 컬렉션 : 서버가 관리하는 리소스 디렉토리, 서버가 리소스 URI를 생성하고 관리한다. 참고 : 신규로 리소스가 생성되면 보통 HTTP 상태 코드 201 created와 location 헤더에 리소스가 생성된 경로를 보낸다. 그냥 200으로 보내도 된다.

PUT

리소스가 있으면 대체하고, 없으면 생성한다.(덮어쓰기) 신규 리소스 등록 시 클라이언트가 직접 리소스의 URI를 지정한다. 스토어 : 클라이언트가 관리하는 리소스 저장소, 클라이언트가 리소스의 URI를 알고 관리한다.

PATCH

업데이트 리소스를 부분적으로 변경한다. 간혹 PATCH를 지원하지 않는 서버가 있을 수 있는데, 이 경우 POST를 사용하면 된다.

DELETE

• 리소스를 삭제한다.
• DELETE : 리소스 삭제

이 밖에 HEAD, OPTIONS, CONNECT, TRACE가 있다.

• HEAD : GET과 동일하지만, 상태 줄과 헤더만 반환.(본문을 포함하지 않는다)
• OPTIONS : 대상 리소스에 대한 통신 가능 메서드를 설명(주로 CORS에서 사용)
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정.
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행.

HTTP 메서드의 속성

안전(Safe)

호출해도 리소스를 변경하지 않는다.

멱등(Idempotent)

• 몇 번을 호출하든 결과가 똑같다.

• 멱등 메서드

  • GET
  • PUT : 리소스를 대체하는 것이기 때문에, 같은 요청을 여러 번 해도 최종 결과는 같다.
  • DELETE : 리소스를 삭제하기 때문에, 같은 요청을 여러 번 해도 삭제된 결과는 같다.

-P OST는 멱등이 아니다. 주문을 예로 들었을 때, 같은 주문이 중복해서 발생할 수 있다.

• 자동 복구 메커니즘에 활용 자동 복구 메커니즘 : 서버가 TIMEOUT 등으로 정상 응답을 주지 못했을 때, 클라이언트가 같은 요청을 자동으로 다시 보낸다.

캐시 가능(Cacheable)

응답 결과 리소스를 캐시해서 사용해도 되는지? GET, HEAD, POST, PATCH 캐시 가능지만 실제로는 GET, HEAD 정도만 캐시로 사용한다. POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.

출처 : https://ko.wikipedia.org/wiki/HTTP

참고하면 좋을 URI 설계 개념

문서(document)

단일 개념(하나의 파일, 객체 인스턴스, DB row) 예: /orders/100, /image/star.png

컬렉션(collection)

서버가 관리하는 리소스 디렉토리 서버가 리소스의 URI를 생성하고 관리한다.

스토어(store)

클라이언트가 관리하는 리소스 저장소 클라이언트가 리소스의 URI를 알고 관리한다.

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

문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스를 실행 동사를 직접 사용한다. 예: members/{id}/delete