Network

[Network] HTTP에 대해서 알아보자!! (4편 - HTTP Method)

coding-knowjam(코딩노잼) 2022. 1. 13.

728x90

안녕하세요 coding-knowjam입니다.

오늘은 HTTP 메서드에 대해서 알아보겠습니다.

1. HTTP Method (HTTP 메서드)

HTTP 메서드는 대표적으로 유명한 GET과 POST가 있고, 실제로 현업에서 개발을 할 때도 가장 많이 보셨을 거예요

메서드가 수행하는 역할은 무엇일까요??

앞서 포스팅했던 것들을 통해서 유추가 가능하지만 HTTP 메서드는 클라이언트가 요청을 할 때, 서버에서 수행되기를 바라는 동작을 의미합니다.

우리가 앞서 살펴본 요청 메시지의 시작 라인에는 HTTP 메서드를 작성해야 합니다.

예를 들어 "GET /menus HTTP/1.1"이라는 요청 메시지가 있을 때, 서버는 menu 목록을 조회하는 동작을 수행할 것입니다.

동일한 리소스에 대해서 "POST /menus HTTP/1.1"이라는 요청 메시지(메시지 바디에 데이터 포함)가 서버에 전달되면, 서버는 menu를 신규 등록하는 동작을 수행할 것입니다.

이처럼 동일한 리소스에 대해서 행위를 지정할 때 우리는 HTTP 메서드를 사용할 수 있습니다.

(앞서 URI는 식별 가능한 자원인 리소스를 가리킨다고 말씀드린 것 아직 있지 않으셨죠??)

이제 일반적으로 많이 사용되는 메서드들에 대해서 알아보겠습니다.

1.1 GET Method

GET 메서드는 리소스를 조회할 때 사용
조회 용도로 사용하기 때문에 여러 번 실행해도 안전하며, 동일한 응답이 보장되므로 멱등성을 가짐
조회 시 필요한 정보는 URI에 쿼리 파라미터를 붙여서 전달 (GET /menus?type=noodle HTTP/1.1)

GET 요청 예시 (출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본지식)

쿼리 파라미터 외에 메시지 바디에도 정보를 전달할 수 있음 (서버가 지원하지 않는 경우가 있기 때문에 일반적으로 쿼리 파라미터를 사용)
URI에 쿼리 파라미터가 노출되므로 보안상 중요한 정보를 조회할 때는 사용하는 것을 지양
동일한 요청에 대해 캐시 가능
공식문서 : https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.1

그리고 참고로 GET 메서드에 대해서 URL에 데이터를 같이 전달하기 때문에 실제로 보낼 수 있는 데이터의 길이에 제약이 있다고 알고 계시는 분들이 아직 있을까 봐 말씀드립니다.

결론적으로 이는 잘못된 이야기입니다. 이전에 IE(익스플로러)가 256바이트만 지원을 했었기 때문에, 웹 브라우저 호환성 때문에 256바이트 길이 제한이라는 이야기가 나온 것으로 보입니다.

애초에 RFC 공식문서에서도 길이에 제한을 두지 않는 것으로 되어있으며, 우리는 브라우저 호환성 때문에 길이 제약이 있는 것으로 알게 된 것입니다. (https://datatracker.ietf.org/doc/html/rfc2616#section-3.2.1)

1.2 HEAD Method

GET과 동일한 형태로 요청을 보내지만 응답에서 메시지 바디를 제외하고 받음
GET처럼 안전성과 멱등성을 가짐
동일한 요청에 대해 캐시 가능
공식문서 : https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.2

1.3 POST Method

서버에 데이터 처리를 요청할 때 사용 (데이터 신규 등록, 특정 비즈니스 로직 수행 등)
요청 시 메시지 바디에 데이터를 담아서 서버에 전달하고 서버는 이를 처리 (아래 그림 참조)

POST 요청 예시 (출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본지식)

신규 리소스 등록 요청 처리 시 서버는 응답에 Location헤더 포함 (아래 그림 참조)

POST 응답 예시 (출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본지식)

공식문서 : https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.3

앞서 우리는 GET이 리소스를 조회할 때 사용한다고 말씀드렸습니다.

POST는 GET처럼 명확하게 어떠한 행위가 정해지지 않았으며, 서버에 어떠한 처리를 요청할 때 사용하게 됩니다.

일반적으로 신규 리소스를 생성할 때 사용하지만, 꼭 리소스를 생성하는 상황에만 사용하는 것은 아닙니다.

결국 어떠한 URI에 대해서 POST메서드가 매핑되었을 때, 서버에서 이를 어떻게 처리할지를 정하는 것입니다.

아마 실무에서 레거시 코드들을 보면 GET과 POST만으로 모든 요청과 응답을 처리한 사례도 보실 수 있을 겁니다.

그래서 POST는 만능(?)으로 쓰일 수 있지만 행위가 명확히 구분되는 경우는 해당 메서드를 사용하시고, 애매한 경우에는 POST 메서드를 사용하면 됩니다.

1.4 PUT Method

리소스를 대체할 때 사용 (리소스가 없으면 생성, 있으면 대체)
여러 번 실행해도 동일한 결과를 보장하므로 멱등성을 가짐
요청 URI에 리소스의 위치를 명확히 지정 ("PUT ~/menus/1 HTTP/1.1")
요청 시 메시지 바디에 대체할 데이터를 담아서 요청 (아래 그림 참조)
공식문서 : https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.4

PUT 요청 예시 (출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본지식)

리소스를 대체한다는 것은 데이터의 부분적인 변경과 다르다는 점을 기억하셔야 합니다.

위의 예시 요청에서 age항목이 빠져있다면, PUT 요청이 처리된 이후 해당 리소스는 age항목이 null값이 될 겁니다.

이렇게 요청 시 전달된 정보로 해당 리소스의 데이터를 완전히 대체하므로, 부분적인 변경이 필요한 경우 PATCH를 사용하셔야 합니다.

1.5 PATCH Method

리소스의 데이터를 부분 변경할 때 사용
요청 시 변경할 데이터를 메시지 바디에 담아서 서버에 전달 (아래 그림 참조)

PATCH 요청 예시 (출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본지식)

PATCH는 PUT메서드와 리소스의 데이터를 변경한다는 점에서는 비슷한 부분이 있지만 멱등하지 않다는 점을 기억해야 합니다.

왜냐하면 데이터의 변경이 꼭 대체가 아니라 증가하거나 감소하는 형태로 서버에서 설계될 수도 있기 때문입니다.

예를 들어 위의 예시 요청에서 age : 50을 전달하지 않고 그냥 해당 URI를 PATCH메서드로 요청하면 age가 10 증가하는 형태로 서버에서 처리한다면 멱등하지 않기 때문입니다.

1.6 DELETE Method

리소스를 삭제할 때 사용
삭제 시 리소스의 위치를 지정해서 요청 (아래 그림 참조)
여러 번 호출해도 동일한 결과를 응답하므로 멱등성을 가짐

DELETE 요청 예시 (출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본지식)

지금까지 일반적으로 자주 쓰이는 HTTP 메서드에 대해서 다뤄보았습니다.

이제 실제로 이러한 메서드를 사용해가면서 HTTP API 설계를 어떻게 해야 할지 고민이 될 텐데요

이 부분은 추후 포스팅에서 다루기로 하고, 다음에는 상태 코드에 대해서 알아보겠습니다.

해당 포스팅은 인프런 - 모든 개발자를 위한 HTTP 웹 기본지식을 참고하였습니다.