📌 HTTP 메서드
: 클라이언트와 서버 사이에 이루어지는 요청에서, 서버에 주어진 리소스에 수행하길 원하는 행동이다. 주로 사용되는 HTTP 메서드는 (CRUD(Create, Read, Update, Delete)에 해당하는) GET, POST, PUT, DELETE, 그리고 PATCH이다.
(이외에도 HEAD, OPTIONS, CONNECT, TRACE까지 총 9가지가 있으나, 주로 쓰이는 메서드를 중심으로 알아보자.)
GET : 리소스 조회 메서드(Read)
- 리소스를 조회하는 메서드이다.
- 서버 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달한다.
- URL 헤더에 정보를 넣는 방식이므로 URL 길이 제한에 영향을 받는다.
- 리소스 조회는 POST도 사용할 수 있지만, GET 메서드는 캐싱이 가능하기에 GET을 사용하는 것이 유리하다.
GET 예시
GET /search?q=hello&hl=co HTTP/1.1 Host: www.google.com
POST : 전달한 데이터 처리/생성 요청 메서드(Create)
- 요청 데이터를 처리하는 메서드로, 주로 전달된 데이터로 신규 리소스를 등록하거나, 프로세스 처리에 사용한다.
- 서버에 전달하고 싶은 데이터는 메시지 바디(body)를 통해 전달한다. 서버에서는 이 요청 데이터를 처리해 업데이트한다.
- Ex) 회원가입을 통해 새로운 사용자 추가 / 신규 주문 생성 / 한 문서 끝에 내용 추가 등
- 만일 데이터를 GET하기엔 JSON으로 조회 데이터를 넘겨야 하는 애매한 경우에 POST를 사용한다.
POST 예시
POST /members HTTP/1.1 Content=Type: application/json { "username": "hello", "age": 20 }
PUT : 리소스를 대체(수정)하는 메서드(Update)
- 리소스를 완전히 대체하는 메서드이다.
- 만일 요청 메시지에 리소스가 있으면 덮어쓰고, 없으면 새로 생성한다.
- 데이터를 대체해야 하니, 클라이언트가 리소스의 구체적인 전체 경로를 지정해 보내주어야 한다.
PUT 예시
PUT /members/100 HTTP/1.1 Content-Type: application/json { "username": "hello", "age": 20 }
PATCH : 리소스를 부분적으로 변경하는 메서드(Update)
-
PATCH를 지원하지 않는 서버에서는 PATCH를 대신해 POST를 사용할 수 있다.
-
PUT과 PATCH의 차이
{ "name": "KSH", "age": 20 }
위와 같은 /student/100이 있다고 치자.
{ "age": 50 }
이러한 본문이 있을 때, PUT과 PATCH의 결과(응답)가 서로 다르다.
➡️ PUT의 경우 기존 데이터가 완전히 대체되어 이름 데이터가 삭제되는 반면, PATCH의 경우 이름은 그대로 남고 age만 50으로 변경된다.
(사실 PUT을 PATCH처럼 쓸 수 있기에 PATCH는 잘 사용하지 않는다)
PATCH 예시
PATCH /members/100 HTTP/1.1 Content-Type: application/json { "age": 50 }
DELETE : 리소스를 제거하는 메서드(Delete)
DELETE 예시
DELETE /members/100 HTTP/1.1 Host: localhost:8080(/member/100 경로의 리소스를 제거한다.)
✅ HTTP 메서드의 속성
- 안전(Safe Methods)
: 계속해서 메서드를 호출해도 리소스를 변경하지 않는다는 뜻이다. 즉, HTTP 메서드가 서버의 상태를 바꾸지 않음을 말한다. GET 메서드는 안전하다.- 멱등(Idempotent Methods)
: 메서드를 여러 번 호출해도 결과가 동일함을 말한다. GET, PUT, DELETE는 멱등성을 가진다.- 캐시가능(Cacheable Methods)
: 캐싱을 해서 데이터를 효율적으로 가져올 수 있음을 말한다. GET, HEAD, POST, PATCH 모두 캐시가 가능하나, 실제로는 GET과 HEAD만 주로 캐싱이 쓰인다.
(+) 캐싱(Caching) : 파일 복사본을 캐시 또는 임시 저장 위치에 저장하여 보다 빠르게 액세스할 수 있도록 하는 프로세스
✅ 메서드 비교
- POST방식이 (GET에 비해) URL에 데이터의 정보가 들어 있지 않으므로 비교적 안전하다고 볼 수 있고, 길이 제한이 없다. ➡️ 아래에 추가 설명
- GET방식은 (POST에 비해) 캐싱을 하기 때문에 여러 번 요청 시 저장된 데이터를 활용하므로 조금 더 빠를 수 있다.
- POST와 PUT : POST는 새로운 데이터를 계속 생성하기 때문에 요청할 때마다 데이터를 생성하지만, PUT은 사용자가 데이터를 지정하고 수정하는 것이기에 같은 요청을 계속하더라도 데이터가 계속 생성되지 않는다.
- PUT과 PATCH : 위에서 설명했듯, PUT은 지정한 데이터를 전부 수정하는 메서드이지만 PATCH는 정보의 일부분만 변경하는 메서드이다. 그래서 PUT은 멱등하나 PATCH는 멱등하다고 볼 수 없다.
POST 방식은 안전하다?
GET 방식은 경로에 정보가 포함되어 직접적으로 드러나는 반면 POST는 body에 정보가 포함되기에 비교적 안전한 것은 맞다.
그러나 POST가 더 안전하다고 하는 것은 'GET 방식보다 안전한 것'이지 보안성을 보장해준다는 것은 아님에 유의하자.
📌 HTTP 메서드를 사용하는 이유 : 좋은 API URL 설계
여기서 짚어 두어야 할 점은, "HTTP 메서드 자체에는 기능이 없다"라는 사실이다. 예를 들어, DELETE로 클라이언트에서 서버로 리소스 경로를 보내주면 자동으로 해당 데이터가 삭제되는 것이 아니다. 개발자가 그렇게 동작하도록 구현해 주어야 한다. 즉, 요청에 대한 동작은 메서드 자체가 아닌 개발자의 구현에 의해 이루어진다는 것이다. 서버에서 DELETE 메서드 요청을 통해 신규 리소스가 생성되게 구현하면 그렇게 동작하고, 반대로 POST 메서드 요청을 통해 리소스를 삭제하게 만들 수도 있다. (쉽게 말해, HTTP 메서드인 GET, DELETE 등은 '함수 이름'에 불과하며, 그것을 구현함은 개발자의 역할이다.)
🧐 그럼 HTTP 메서드는 왜 필요할까?
그 이유는, '리소스(자원)와 행위를 분리'하기 위해서이다. 좋은 API URL 설계는 리소스와 행위가 분리되어 있어야 한다. 즉, URL에 행위가 포함되어 있으면 좋은 설계가 아니라는 의미다. 회원 정보를 관리하는 API URL을 설계한다고 가정해 보자.
- 회원 목록 조회 : /read-member-list
- 회원 조회 : /read-member-by-id
- 회원 등록 : /create-member
- 회원 수정 : /update-member
- 회원 삭제 : /delete-member
위와 같이 URL에 리소스와 행위가 포함되어 있는 것보다
- 회원 목록 조회 : /members - GET
- 회원 조회 : /members/{id} - GET
- 회원 등록 : /members/{id} - POST
- 회원 수정 : /members/{id} - PATCH & PUT
- 회원 삭제 : /members/{id} - DELETE
이처럼 리소스만 깔끔하게 보이고 행위는 HTTP method로 구분하게끔 설계하는 것이 유지보수측면에서 훨씬 유리하다. 이러한 설계에 대한 개념은 'REST API'에 관한 설명으로 더 깊이 이해할 수 있겠다.
(후에 REST API에 관해서도 자세히 정리해 보자.)
(+) REST API 맛보기!
REST API란, HTTP 요청을 보낼 때 어떤 URI와 어떤 메서드를 사용할지 개발자들 사이에 널리 지켜지는 약속이다!
(+) REST 는 Representational State Transfer 의 약자이다. 해석하면 "표현을 통한 상태 전달" 정도로 볼 수 있다. REST를 잘 설명할 수 있는 해석은 "표현(자원, 결과의 표현방식)에 따른 상태의 전달" 이 더 정확할 것 같다.
(생활코딩) 기계와 기계가 규격화된 방식으로 통신할 수 있도록 돕는 통신 규약 - REST API는 HTTP를 이용한다.
