HTTP 메서드(GET,POST)

인프런 강의 中 
김영한 강사님의 '모든 개발자를 위한 HTTP 웹 기본 지식' 내용을 정리했습니다.

이미치 출처: https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC#

 

안녕하십니까, 꽤나 만족스러운 20대를 보내고 있는 웅쓰입니다. 아직 20대가 3년 정도 남았는데요, 더욱 도전하는 삶을 살며 남은 20대를 멋지게 장식해 보겠습니다😋. 오늘은 HTTP API를 만들 때 가장 많이 사용했던 GET과 POST 방식에 대해서 김영한 강사님의 강의를 토대로 학습해 보겠습니다!

 

 

목차

• HTTP API를 만들어보자.
• HTTP 메서드 - GET, POST
• HTTP 메서드 - PUT, PATCH, DELETE
• HTTP 메서드의 속성

 

이번 챕터의 핵심은 HTTP 메서드들이 어떤 상황에서 사용해야 하는지 이해하는 것이라 생각한다. 고로 상황별로 분석해보겠다!

1. HTTP API를 만들어보자.

 

다음과 같은 기능을 하는 회원 정보 관리 API를 만들라는 요구사항이 있다고 가정하자.

• 회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제

해당 요구사항에 맞는 URI를 만들어야 하는데 단순히 한국어를 영어로만 바꿔서 만들면 될까? 마치 회원 목록 조회를 /read-member-list처럼 말이다. 이렇게 URI를 만들면 중복되지 않는 URI를 만들 수 있어서 좋다고 생각하지만 사실 이건 옳지 않은 방법이다.(불가피한 경우에는 해야하긴 함.) 그럼 어떤 기준으로 URI를 만들어야 할까?

 

리소스를 기준으로 API URI를 설계

여기서 리소스란 행위가 아니라 개체에 해당하는 부분이다. 즉, 등록하고 수정하는 동사는 배제하고 회원이라는 개체만 리소스에 해당이 된다. 그럼 이렇게 식별한 리소스를 토대로 API URI를 설계하면 다음과 같다.

• 회원 목록 조회 : /members
• 회원 조회 : /members/{id}
• 회원 등록 : /members 
• 회원 수정 : /members/{id}
• 회원 삭제 : /members/{id}

리소스를 기준으로 URI를 설계하니까 깔끔해 보이긴 하는데.. 회원 조회, 등록, 수정, 삭제 URI이 같아서 각 기능을 구분할 수 없다.. URI는 같지만 저마다 다른 기능을 하는 URI라고 구분을 해줘야 원하는 기능을 제대로 할 것이다. 이때, 구분을 해주는 녀석이 HTTP 메서드들이다.

 

HTTP 주요 메서드 종류

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

기타 메서드 종류

• HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명
• CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

필자는 개인적으로 URI가 리소스, HTTP 메서드가 행위라고 이해하고 둘을 합쳐서 API를 만들자라고 생각하고 넘어갔다. 필자가 이해한대로 회원 조회, 등록, 수정 삭제 API를 만든다면

• 회원 조회 : /members/{id} GET 요청
• 회원 등록 : /members POST 요청
• 회원 수정 : /members/{id} PATCH 요청
• 회원 삭제 : /members/{id} DELETE 요청

이렇게 될 것이다. 그럼 원하는 기능을 리소스를 기준으로 설계한 URI를 통해 할 수 있다. so good~~! 

 

HTTP 메서드가 API의 행위를 구분짓는 만큼 각자의 특성이 있을 것이다. 단순히 '조회는 GET 요청으로만 하세요~'라고 정의만 해놓진 않았을 것이다. 각 메서드들을 조금 더 자세히 학습해보자.

 

2. HTTP 메서드 - GET, POST

(1). GET

리소스 조회 기능을 담당하는 메서드이며 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달한다. ex) /search?q=hello

메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다. 여기서 메시지 바디를 사용해서 데이터를 전달 및 조회하는 상황을 예로 하나 들자면 비동기 요청 상황이다.

필자도 GET은 메시지 바디를 지원하지 않는 곳이 있기에 권장하지 않는다는 내용을 몰랐어서 마냥 조회하는 기능이면 GET을 사용하면 되겠지하고 아래와 같은 코드를 작성했었다.

 

위 코드가 에러를 발생시키진 않았지만, 조회 기능이어도 body를 통해 데이터를 백엔드로 전송해야 할 때는 POST를 써야겠다고 생각했다.

 

클라이언트가 서버로 GET 요청을 했을 때 송수신되는 데이터를 한번 순서대로 살펴보겠다.

 

클라이언트 GET 요청

클라이언트가 서버에 GET방식으로 리소스 요청

 

가장 처음 클라이언트가 서버에 GET 요청을 한다. 요청시 HTTP 메시지는 이전 시간에서 다뤘던 HTTP 메시지 구조의 형태로 전송된다. 메시지의 URI를 보면 '/members/100에 해당하는 데이터를 조회해줘~'라는 요청이라는 것을 알 수 있다. 해당 요청을 받은 서버는 알맞은 데이터를 조회한다.(위에서는 조회한 데이터를 JSON형태로 가지고 있음)

 

서버 GET 응답 메시지 회신

서버가 클라이언트로 GET 요청에 대한 데이터 응답

 

조회한 데이터를 응답 메시지의 body부분에 담아서 클라이언트로 전송한다. 이 때, 보통은 JSON 형태로 메시지 body에 담아 전송한다. 응답이 성공적이면 위 메시지처럼 200 OK 사인을 담아서 전송한다. 

 

지금까지 GET 요청 흐름과 송수신되는 데이터 및 메시지 구조를 살펴보았다.

 

(2). POST 

POST의 개념적인 사용법도 중요하지만 필자는 개인적으로 그냥 POST는 모든 것을 할 수 있는 만능 메서드라고 생각한다. POST를 통해 조회 기능도 요청할 수 있지만 캐싱 같은 이유 혹은 처음 예시처럼 URI가 같아서 백엔드단에서 구분자가 필요한 상황에서 사용할 뿐 어떤 에러도 발생하지 않는다. 고로 필자는 POST가 만등 메서드라고 생각한다. 이제 필자의 생각은 됐고, 개념적으로 POST가 언제 사용되는지 정리해보자.

 

POST는 요청 데이터를 처리하는 기능을 담당하는 메서드이며 메시지 바디를 통해(GET 메서드와 다른점) 클라이언트가 서버로 요청 데이터를 전달한다. 그리고 서버는 요청 데이터를 처리해준다. 이때, 서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다. POST를 사용하는 상황을 3가지로 나눌 수 있다.

 

1) 새 리소스 생성 및 등록

    - 아직 서버에 존재하지 않는 새 리소스를 생성할 때 사용

2) 요청 데이터 처리

    - '결제 완료 -> 배달 시작'과 같이 데이터의 변경을 넘어 프로세스의 변경이 수행되는 경우(배달이 시작되면 단순히 텍스트만 변경이 되                             는게 아니라 배달 직원 매칭, 배달 소요 시간 예상 등 다양한 프로세스들이 수행되겠져? 그럴 때 쓰인답니다.)

3) 다른 메서드로 처리하기 애매한 경우

    - 필자가 위에서 언급했든 비동기로 JSON 형태의 조회 데이터를 서버로 넘겨야 할 때, 조회 기능이지만 GET보단 POST가 유리

 

이렇게 POST를 사용하는 상황을 정리해 보았는데, 필자는 이 상황에서는 어떤 메서드를 써야하지?라고 고민이 된다면 그냥 POST를 쓰기러 마음 먹었다...(물론 뒤에 나오는 PUT, PATCH, DELETE까지 고려한 이후에!)

 

클라이언트가 서버로 신규 리소스 생성을 위해 POST 요청을 했을 때 송수신되는 데이터를 한번 순서대로 살펴보겠다.

 

클라이언트 POST 요청

클라이언트가 서버로 POST 요청

 

클라이언트는 메시지 바디에 요청 데이터를 넣어서 서버에 전달한다.

 

신규 리소스 생성

서버에서 신규 리소스 식별자 생성

 

클라이언트의 요청 데이터를 전달받은 서버는 요청 데이터를 DB에 생성하고 신규 리소스 식별자를 생성한다.(위에서 100이 신규 리소스 식별자)

 

서버 POST 응답 메시지 회신

응답 데이터 회신

 

서버는 새로운 리소스 생성 성공 메시지인 201 Created 사인과 생성 Location 정보 등을 클라이언트에게 회신한다.

 

지금까지 POST 요청 흐름과 송수신되는 데이터 및 메시지 구조를 살펴보았다. POST는 정말 다양한 상황에서 사용할 수 있기에 응답 데이터 같은 경우 위 모습과 조금 다를 수 있지만 어느정도의 구조는 동일할 것이다.

 

여기까지 GET과 POST 사용법에 대해 이해를 했다면 Success!!

 

 

 

김영한 강사님 강의!!

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 | 김영한 - 인프런