HTTP 메서드의 속성

HTTP메소드

주요 메소드

GET: 리소스 조회 POST: 요청 데이터 처리, 주로 등록에 사용 PUT: 리소스를 대체, 해당 리소스가 없으면 생성 PATCH: 리소스 부분 변경 DELETE: 리소스 삭제

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

POST

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야한다. 정해진 방법은 없음

POST정리

1. 새 리소스 생성

• 서버가 아직 식별하지 않은 새 리소스 생성

1. 요청 데이터 처리

• 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우

예) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우

• POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음

예) POST /orders/{orderId}/start-delivery (컨트롤 URI)

1. 다른 메소드로 처리하기 애매한 경우

ex) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

PUT

• 리소스가 있으면 덮어버리고, 없으면 생성한다.
• POST와 큰 차이점으로 클라이언트가 리소스 위치를 알고 URI를 지정

 

여기서 덮어버린다는 의미는 만약 JSON형태로 리소스를 받는다고 하면 원래 리소스에 2개의 KEY다고 가정하자

PUT메소드를 사용해 기존에 있던 두 개의 KEY중 한 개만 리소스를 받으면 PUT으로 새로 받은 리소스만 유지된다.

PATCH

• PUT와 다르게 리소스 부분 교체
• 간혹가다가 PATCH가 지원이 안되는 서버가 있다 그런 경우 POST사용

DELETE

• 리소스 제거

HTTP 메소드의 속성

안전

• 호출해도 리소스를 변경하지 않는것을 말한다.

추가적으로 우리가 일반적으로 생각하는 안전과는 다르게 리소스만 고려하기 때문에 장애가 발생해도 고려하지 않는다.

멱등(Idempotent)

• 몇 번을 호출하든 결과가 같아야 한다.

멱등은 서버가 클라이언트에게 어떠한 이유로 정상 응답을 못 주었을때, 활용 할 수 있다. 왜냐하면 같은 요청을 해도 결과는 같기 때문이다.

멱등 메소드

GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다. PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다. DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

캐시가능(Cacheable)

캐시 가능성은 응답 결과 리소스를 캐싱해서 가져올 수 있는 여부이다

캐시(Cache)가 꼭 운영체제나 서버에만 있는 것이 아니라, 브라우저 자체도 하나의 소프트웨어라 캐시 공간을 가지고 있는데, 클라이언트가 서버에 한 번 요청했던 데이터에 대해 매 요청마다 다시 전송할 필요가 없도록 브라우저가 임시적으로 데이터를 보관하고 있는 장소이다. 즉, 캐싱이 가능한 HTTP 메소드는 빠르게 결과값을 받을 수 있다는 소리이다.

캐시 가능 메소드

GET, POST, PATCH, HEAD - 스펙상으로 가능 GET, HEAD - 실무에서 사용하는 메소드

=> 왜냐면 캐시를 하려면 똑같은 리소스에 대해서 캐시 KEY 가 정확히 맞아야한다. POST, PATCH 는 본문(Body) 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다

HTTP메소드

주요 메소드

GET: 리소스 조회 POST: 요청 데이터 처리, 주로 등록에 사용 PUT: 리소스를 대체, 해당 리소스가 없으면 생성 PATCH: 리소스 부분 변경 DELETE: 리소스 삭제

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

POST

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야한다. 정해진 방법은 없음

POST정리

1. 새 리소스 생성

• 서버가 아직 식별하지 않은 새 리소스 생성

1. 요청 데이터 처리

• 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우

예) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우

• POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음

예) POST /orders/{orderId}/start-delivery (컨트롤 URI)

1. 다른 메소드로 처리하기 애매한 경우

ex) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

PUT

• 리소스가 있으면 덮어버리고, 없으면 생성한다.
• POST와 큰 차이점으로 클라이언트가 리소스 위치를 알고 URI를 지정

 

여기서 덮어버린다는 의미는 만약 JSON형태로 리소스를 받는다고 하면 원래 리소스에 2개의 KEY다고 가정하자

PUT메소드를 사용해 기존에 있던 두 개의 KEY중 한 개만 리소스를 받으면 PUT으로 새로 받은 리소스만 유지된다.

PATCH

• PUT와 다르게 리소스 부분 교체
• 간혹가다가 PATCH가 지원이 안되는 서버가 있다 그런 경우 POST사용

DELETE

• 리소스 제거

HTTP 메소드의 속성

안전

• 호출해도 리소스를 변경하지 않는것을 말한다.

추가적으로 우리가 일반적으로 생각하는 안전과는 다르게 리소스만 고려하기 때문에 장애가 발생해도 고려하지 않는다.

멱등(Idempotent)

• 몇 번을 호출하든 결과가 같아야 한다.

멱등은 서버가 클라이언트에게 어떠한 이유로 정상 응답을 못 주었을때, 활용 할 수 있다. 왜냐하면 같은 요청을 해도 결과는 같기 때문이다.

 

멱등 메소드

GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다. PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다. DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

캐시가능(Cacheable)

캐시 가능성은 응답 결과 리소스를 캐싱해서 가져올 수 있는 여부이다

캐시(Cache)가 꼭 운영체제나 서버에만 있는 것이 아니라, 브라우저 자체도 하나의 소프트웨어라 캐시 공간을 가지고 있는데, 클라이언트가 서버에 한 번 요청했던 데이터에 대해 매 요청마다 다시 전송할 필요가 없도록 브라우저가 임시적으로 데이터를 보관하고 있는 장소이다. 즉, 캐싱이 가능한 HTTP 메소드는 빠르게 결과값을 받을 수 있다는 소리이다.

 

캐시 가능 메소드

GET, POST, PATCH, HEAD - 스펙상으로 가능

GET, HEAD - 실무에서 사용하는 메소드

 

=> 왜냐면 캐시를 하려면 똑같은 리소스에 대해서 캐시 KEY 가 정확히 맞아야한다. POST, PATCH 는 본문(Body) 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다

 

 

참조: 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한