[이것이 백엔드 개발이다/한빛미디어] CH08. 서버와 클라이언트의 약속, HTTP (2) - 2. HTTP 요청 헤더와 바디

HTTP 요청 살펴보기

• 실제 HTTP 요청 헤더 보기 : [Network] - [backend.html] - [Headers] - [Request Headers] - [view source]

• HTTP 요청은 크게 헤더, 바디로 나눌 수 있다.
• 다시 헤더는 첫 번째 줄, 나머지 줄로 나눌 수 있다.

GET /backend.html HTTP/1.1

• GET : HTTP 요청 메서드로 'GET' 사용
• /backend.html : 해당 요청이 어떤 경로로 가는지
• HTTP/1.1 : 해당 요청의 HTTP 버전

▶ 경로 & HTTP 버전 확인 중요한 경우

HTTP/1.1에서 HTTP/2로 변경하고 있는 상황

 

위와 같은 경우가 아니라면, 크게 신경 써야 할 내용은 아닐 가능성이 높다.

그러나, GET과 같은 HTTP 요청 메서드는 매우 중요하므로 좀 더 알아볼 필요가 있다.

 

HTTP 요청 메서드

같은 경로에 대산 HTTP 요청이더라도 메서드에 따라 동작이 달라지도록 개발해야 한다.

어떤 메서드를 사용할지 고민할 때, 참고하도록 하자.

 

   행위별로 적절한 HTTP 메서드 연결   

• GET : 특정 자원에 대한 조회 요청
• HEAD : GET과 동일, 바디 제외한 헤더 부분만 응답으로 받음
• POST : (요청 바디에 있는 내용을 바탕으로 생성 된)새로운 자원 생성 요청
• PUT : 기존 자원을 요청 바디에 있는 내용으로 변경
• PATCH : 기존 자원 일부만 변경
• DELETE : 특정 자원 제거
• OPTIONS : 해당 경로에서 어떤 HTTP 요청 메서드 사용 가능한지 알려줌

▶ CRUD 별 적절한 HTTP 메서드

CRUD
: Create, Read, Update, Delete

• Create : POST
• Read : GET
• Update : PUT
• Delete : DELETE

일반적으로 위의 메서드를 해당 상황에 적용하여 API를 설계한다.

이를 이해하기 위해 HTTP 메서드의 중요 특징 2가지를 알아보자.

1. 안전한 메서드
2. 멱등성 있는 메서드

◎ 안전한 메서드

: 대상이 되는 자원 상태를 변경하지 않는 메서드.

EX) 즐겨찾기 서비스 - 즐겨찾기 이름 변경 X, 즐겨찾기 URL 변경 X.

• 안전한 메서드 : GET, HEAD, OPTIONS
• GET 메서드로 @RequestMapping 추가 시 WAS가 'HEAD, OPTIONS'에 자동 생성해줌
  • 따라서 GET 메서드 API를 '안전한 메서드'로 만들어야 함.
  • GET 메서드라면 자원의 상태를 변경하지 않아야 한다.
• GET 메서드는 웹 브라우저에서 특정 URL에 접속하기만 해도 요청 날아갈 위험 있음
  • 따라서 자원 상태 변경 API에 GET 메서드 사용 지양해야 함.

◎ 멱등성 있는 메서드

: '한 번 호출한 것' & '여러 번 호출한 것'이 같은 자원의 상태를 가지는 것.

EX) 티켓팅 사이트에 좌석 선점 요청을 하는 경우 - 사용자 A가 좌석 B를 선점하는 요청을 한 번 보내든 여러 번 보내든, A는 좌석 B를 1개만 선점하게 됨.

• GET : 읽기 연산은 안전해야 하고, 호출해도 자원 상태 바뀌지 않기 때문.
• PUT : (수정) 동일 내용으로 요청하면 한 번 수정 된 후 동일 상태를 가지기 때문.
• DELETE : (삭제) 해당 ID 기준 삭제 요청 시, 한 번 삭제된 후로는 동일하게 자원이 삭제된 상태 유지하기 때문.
• POST : 생성하기는 멱등성이 없다.
• PATCH : (일부 수정) 자원 일부만 수정하는 기능 & 멱등성 없을 경우.

▶ HEAD, OPTIONS

HEAD, OPTIONS로 요청한다면 ?

HEAD 메서드로 요청 시, 응답 바디에는 아무것도 나오지 않는다.

HEAD 메서드 사용 시, GET 메서드 호출 때와 동일하게 헤더는 볼 수 있지만, 응답 바디는 비어 있다.

∴ HEAD 메서드는 '응답 헤더'만 볼 수 있다.

 

그렇다면, GET 메서드로 호출한다면 어떻게 될까 ?

HEAD & GET 모두 응답 헤더 내용은 동일하다.

그러나, GET 메서드는 응답 바디가 있다.

 

그럼 HEAD 메서드는 어디에 사용 가능한가 ?

→ '크롤러' 등에 사용 가능하다.

EX) 웹 페이지를 돌아다니며 'HTTP' 문서 수집하는 '크롤러' 프로그램

'한 번 다운로드 된 페이지는 변경되지 전까지 다시 다운로드하지 않는다' 규칙 사용.

∵ 웹 페이지 다운로드는 '트래픽'을 유발, 트래픽은 비용으로 직결됨

 

그렇다면, 크롤러 시 불필요한 다운로드에 소모되는 트래픽을 줄이려면 어떻게 해야 할까 ?

일단, Postman에서 HEAD 메서드로 요청하여 응답이 온 HTTP 응답 헤더를 보면, 'Last-Modified' 헤더를 볼 수 있다.

이 응답 헤더를 사용하여 코드를 작성하면 된다.

1. GET 요청(처음 웹 페이지 수집 시) 후 해당 웹 페이지의 'URL' & 'Last-Modified 헤더 값' 함께 저장.
2. 일정 주기 지나고 수집 완료한 웹 페이지 변경 여부 확인 위해 'HEAD 요청' 후, 'Last-Modified' 변경 여부 확인.
3. 변경 여부 확인.
   1. O : 'Get 요청' 후 재다운 & 'Last-Modified 헤더 값' 갱신.
   2. X : 재다운 할 필요 없음.

 

OPTIONS 요청하면 해당 경로로 어떤 HTTP 메서드 요청이 가능한지 보여 준다.

→ '/backend.html' 경로는 GET, HEAD, OPTIONS 메서드로 요청 가능.

 

HTTP 요청 바디와 데이터 전달 방식

각 데이터 전달 방식이 HTTP 요청 헤더, 바디 어떤 부분에 담겨 전달 되는가 ?

• URL 통한 데이터 전달
• 요청 바디 통한 데이터 전달

▶ URL로 데이터 전달

• Query Parameter / Query String (쿼리 파라미터 / 쿼리 스트링)
  • URL 일부로 데이터 전송 방식
  • @RequestParam : 쿼리 파라미터로 보낸 데이터를 컨트롤러 쪽에서 활용할 때 사용
  • 장점) 단순 URL 링크만으로 데이터 전달 가능
  • https://www.google.com/search?q=HTTP+Request&newwindow=1&...
    • key = value
  • 필터 조건, 정렬 방식 등 지정 (EX. 구글 검색 결과 : 필터)
• Path Variable (패스 베리어블)
  • 특정 자원 그 자체를 지칭할 때 사용
  • id가 123인 article 조회
    • /article/123
    • /article?id=123
      • id가 123이라는 특정 article을 지칭하고 있으므로 Path Variable에 더 적절함.

▶ 요청 바디로 데이터 전달

1. 'application/x-www-form-urlencoded'로 요청했을 때

<form action="./article" method="post" enctype="application/x-www-form-urlencoded">

헤더

바디

 

2. 'multipart/form-data'로 요청했을 때

<form action="./article" method="post" enctype="multipart/form-data">

헤더

바디

'각 데이터를 나누는 문자열'이 헤더에 포함되어 있다.

WebKitFormBoundaryk8hFCSJcmMcoaEh6

 

3. JSON 데이터를 전송했을 때

헤더

바디

바디에 JSON 데이터가 담겨 있다.

• 컨트롤러에서 HTTP 요청 바디에 담긴 JSON 데이터를 '@RequestBody'를 통해 받을 수 있다.

그렇다면, HTTP 요청 시 데이터 전달 방식과 관련해 주의할 점은 무엇이 있을까 ?

• GET 메서드로 데이터 요청하는 경우, 요청 바디에 데이터 넣지 말기.
• 웹 브라우저가 '응답 Content-Type' 잘못 해석한 경우.

▶ 웹 브라우저가 '응답 Content-Type' 잘못 해석한 경우

• Content-Type 헤더
  • HTTP 요청 & 응답 양쪽 헤더에 포함되는 헤더

 

※ HTML 코드가 웹 브라우저에 그대로 보이는 문제 발생

HTML 문서가 코드 그대로 보이는 경우가 가끔 발생한다.

• 웹 브라우저는 서버에서 보내 준 Content-Type 기준으로 바디를 파싱하여 보여 줌.
• 문제 원인 : '웹 브라우저'가 '응답 Content-Type'으로 'text/html' 대신 'text/plain'으로 잘못 보냈기 때문.
  • 응답 Content-Type : text/html → HTML 문서
  • 응답 Content-Type : text/plain → 단순 문자열