개발자 지망생
  • 꾸준히 공부하기!!
  • Spring
    • 스프링 프레임워크 핵심기술 공부 시리즈!
      • 스프링 프레임워크 핵심기술 0 - Spring Boot 와 Spring MVC 차이
      • 스프링 프레임워크 핵심기술 1 - 빈 설정방법과 의존성 주입
      • 스프링 프레임워크 핵심기술 2 - ApplicationContext의 다양한 기능(1)
      • 스프링 프레임워크 핵심기술 3 - ApplicationContext의 다양한 기능(2)
  • 인터넷 & 웹
    • '리얼월드 HTTP' 학습!!
      • HTTP/0.9 ~ HTTP/1.0 (HTTP의 기초 1 - 메소드와 경로, 스테이터스 코드)
Powered by GitBook
On this page
  • 1. 메소드
  • 2. 경로
  • 3. 스테이터스 코드
  • 4. 바디
  • 5. 헤더

Was this helpful?

  1. 인터넷 & 웹
  2. '리얼월드 HTTP' 학습!!

HTTP/0.9 ~ HTTP/1.0 (HTTP의 기초 1 - 메소드와 경로, 스테이터스 코드)

HTTP의 기초인 메소드와 URL , 헤더, 바디, 스테이터스 코드

Previous'리얼월드 HTTP' 학습!!

Last updated 5 years ago

Was this helpful?

HTTP의 기본 요소를 아래 5가지로 정리할 수 있다. (실제 책에서는 메소드와 경로를 하나로 합쳤지만 필자 나누고 싶다.)

  1. 메소드

  2. 경로

  3. 헤더

  4. 바디

  5. 스테이터스 코드

위 내용을 정리해 봤다.

1. 메소드

메드의 경우 HTTP/0.9에서는 실현되지 않았고, 뉴스그룹(유즈넷)이라는 플랫폼에서 부터 도입되어 HTTP/1.0 등장했다. 1.1로 버전이 바뀌면서 사라진 메서드도 존재하고, 추가로 등록된 메서도 있다고 한다.

아래 내용은 2018년 기준 HTTP/1.1 버전의 메드 목록이다. ( 를 참고하여 작성했다.)

메드 명

전송시 구조 (문법)

설명

GET

GET <Request URI>?query_string HTTP/1.1\r\n

Host: <호스트의 호스트 이름 또는 IP 주소> r\n\r\

지정된 Request-URI에있는 자원에 의해 저장되거나 생성 된 것을 검색하는 데 사용된다. 버의 해당 자원은 데이터를 수신하여 사용 및 상호작용 할 수 있다.

GET으로 설정하여 HTML 양식 변수를 제출하면 매개 변수가 조회 문자열로 인코딩되어 GET 요청 메소드를 사용하여 Request-URI의 일부로 HTTP 서버에 제출

POST

POST <Request URI> HTTP / 1.1 r n

Host: <호스트의 호스트 이름 또는 IP 주소> r n Content-Length: <length in bytes>\r\n Content-Type: <content type>\r\n\r\n

<Request URI에 전달할 query_string 또는 데이터>

지정된 Request-URI에있는 자원에 데이터를 제출하는 데 사용된. 서버의 해당 자원은 데이터를 수신하여 사용 및 상호작용 할 수 있다.

POST로 설정된 HTML 양식 변수가 제출되면 매개 변수가 POST 요청 메시지의 본문으로 인코딩되어 HTTP 서버에 제출된다.

HEAD

HEAD <Request-URI> HTTP/1.1\r\n

Host: <호스트의 호스트 이름 또는 IP 주소>\r\n\r\n

HTTP 1.1 서버가 응답에서 콘텐츠를 리턴하지 않아야한다는 점을 제외하고 GET 메소드와 동일하다.

응답으로 HTTP 헤더에 포함 된 메타 정보는 GET 요청에 대한 응답으로 전송 된 정보와 동일해야 하며, 서버에 대한 메타 정보를 얻는 데 사용할 수 있다.

PUT

PUT <Request-URI> HTTP/1.1\r\n Host: <호스트의 호스트 이름 또는 IP 주소>\r\n Content-Length: <length in bytes>\r\n Content-Type: <content type>\r\n\r\n

<파일에 첨부할 데이터e>

데이터를 HTTP 서버로 전송하고 Request-URI로 식별되는 위치에 저장할 수 있다.

OPTIONS

OPTIONS <Request-URI> HTTP/1.1\r\n

Host: <호스트의 호스트 이름 또는 IP 주소>\r\n\r\n

Request-URI로 식별 된 요청 / 응답 체인에서 사용 가능한 통신 옵션에 대한 정보 요청을 나타낸다.

DELETE

DELETE <Request-URI> HTTP/1.1\r\n

Host: <호스트의 호스트 이름 또는 IP 주소>\r\n\r\n

오리진 서버가 Request-URI로 식별 된 자원을 삭제하도록 요청한다.

TRACE

TRACE <Request-URI> HTTP/1.1\r\n

Host: <호스트의 호스트 이름 또는 IP 주소>\r\n\r\n

요청 메시지의 원격 애플리케이션 계층 루프백을 호출하는 데 사용된다.

클라이언트는 요청 체인의 다른 쪽 끝에서 수신되는 내용을보고 해당 데이터를 테스트 및 진단 정보로 사용

CONNECT

CONNECT <Request-URI> HTTP/1.1\r\n

Host: <호스트의 호스트 이름 또는 IP 주소>\r\n\r\n

Request-URI로 식별 된 자원에 대한 프록시 연결을 지정하는 데 사용된다.

가장 흔히 사용되는 메소드는 GET, POST, HEAD 로 간략하게 정리하면 아래와 같다.

  • GET : 서버에 헤더와 콘텐츠를 요청

  • POST : 새로운 문서 투고 (뉴스그룹에서 처럼)

  • HEAD : 서버에 헤더만 요청

2. 경로

경로는 HTTP/0.9에서도 사용된 요소로 클라이언트가 서버로 요청을 보낼때 사용한다.

경로는 URL에 포함되는 내용이다. 문서에서는 URI와 URL이 모두 등장하지만, 우리에겐 URL이 더 익숙할 것이다. 사실 URI의 일부로 URL이 등장했지만, 웹 시스템을 다루는 한 URI와 URL은 거의 같다고 보기 때문에 이후부터는 URL로 말하겠다.

(프로그래밍 언어에서도 루비, C#은 URI를 Go 언어와 파이썬, Node.js는 URL을 사용하며, Java는 URI, URL 클래스를 모두 가지고 있다.)

일반적으로 URL의 구조는 아래와 같다. (구글을 예시로 하지만 실제 존재하는 URL은 아닙니.)

https://www.google.com/search.html?contents=http

여기서 분해를 하면 다음과 같다.

  • https: : 스키마

  • www.google.com : 호스트명

  • search.html?contents=http : 경로

위에서 메소드 목록의 전송시 문법에서도 이를 확인할 수 있다.

GET <Request URI>?query_string HTTP/1.1\r\n

Host: <호스트의 호스트 이름 또는 IP 주소> r\n\r\

여기서 <Request URI>?query_string 에 해당되는 부분이 경로이다.

경로는 즉 집에 있는 '방'이라고 할 수 있다. URL이 '주소'라고 하면 호스트는 '집' 경로는 '방' 이라고 할 수 있다. 같은 집이라도 다른 방에 들어가면 다른 사람이 반기는 것과 같은 느낌이다.

그렇다면 저자가 URL 대신 경로를 HTTP의 기본 요소에 포함시킨 이유는 무엇일까?

그 이유는 서버에서 받아들이는 것은 경로 뿐이기 때문이라고 필자는 생각한다. 실제로 웹 개발 시 컨트롤러에서 request mapping을 할때 호스트 명은 사용하지 않고 경로부분만 사용한다.

3. 스테이터스 코드

만약 잘못된 경로로 요청을 보냈거나, 다른 이유들로 우리가 보낸 요청이 잘 못됐다는 것을 알기 위해선 응답이 필요하다. 이런 응답을 한눈에 알 수 있게 하는 것이 스테이터스 코드이다.

스테이터스 코드도 경로와 마찬가지로 뉴스그룹에서 가져온 기능이다.

404에러, 503에러등 익숙한 그 에러들이 이 스테이터스 코드에 속한다. 스테이터스 코드는 크게 다섯가지 카테고리로 나눌수 있다.

  • 100번대 : 처리가 진행중임을 나타내는 코드로, 100번대 계열은 특수한 용도로 사용되며, 이후에 다루도록 하겠다ㅏ.

  • 200번대 : 가장 기쁜 코드다. 바로 성공했을 때의 응답.

  • 300번대 : 서버에서 클라이언트로 보내는 명령이다. 오류가 아니라 정상 처리 범주에 속하며, 가장 익숙한 것을 리다이렉트 등이 있다.

  • 400번대 : 클라이언트가 보낸 요청에 오류가 있다는 내용이다.

  • 500번대 : 서버에서 오류가 있다는 것을 알리는 내용이다.

각 카테고리 안에서도 다양한 코드들이 있는데 자세한 내용은 아래 링크를 통해 확인할 수 있다.

4. 바디

바디 역시 HTTP/0.9에서 사용됐다. HTTP/0.9는 정말 단순하게 '브라우저가 요청시, 서버에서는 데이터를 돌려준다'라는 기능만 제공했다. 따라서 HTTP/0.9에서는 요청할 경로와 수신받을 데이터인 바디만 존재했다.

(브라우저의 요청에 응답하는 데이터라면 HTML, JSON, 이미지 등 이 될수 있다.)

그렇다면 클라이언트에서 요청을 보낼 때 서버에 특정한 데이터를 주고 싶은 경우는 어떡할까? 그래서 HTTP/1.0부터 요청시 서버로 데이터를 전송 할 수 있도록 송신 바디가 생겼다. (송신 바디 역시 JSON이 될 수 있고 바이너리 데이터 등이 될 수 있다.)

다만 GET 메소드의 경우 송신 바디를 보내지 않는 것이 원칙이다. 책에서는 GET 메소드의 경우도 바디를 존송 할 수 있지만 그닥 추천하지 않는 다고 나와있다. 그러니 단순한 페이지 이동이나 경로에 줄 수 있는 query string을 제외한 다른 데이터들을 서버로 요청시 전달 하고 싶다면 다른 메소드를 사용하는 것이 좋다.

5. 헤더

()

( )

https://www.yeahhub.com/list-http-methods-2018-update/
자세한 스테이터스 코드 내용
활용 참고