HTTP 구조

Request Message

Start Line

메서드, 타켓, 버전으로 구성.

• 메서드: 요청하는 의도. 아래에서 자세히 설명.
• 타겟: Request가 전송되는 목표 주소. 이 위치에 가서 메서드를 수행한다.
• 버전: 버전에 따라 메시지의 구조가 다를 수 있기 때문에 명시. 앞서 게시한 글에서 HTTP/1.0부터 버전을 표시하기 시작했다고 했었음.

headers

request에 대한 추가 정보를 담고 있다.

위에서는 도메인, 연결 주소, 연결 타입, 연결 방식(위에서는 지속 연결)

이외에도 바디의 길이 등 필요시 더 많은 정보를 넣을 수 있다.

header의 종류

• general headers: 공통 헤더. 요청과 응답 모두 적용. 최종적으로 전송되는 데이터와는 무관하다. -
• request headers: 페치 될 자원, 클라이언트 자체의 정보 등을 포함하는 헤더 → 요청 시 필요한 정보들을 담는 헤더
• response headers: 위치 또는 서버 자체의 정보와 같이 응답에 관한 부가정보를 갖는 헤더 → 응답 시 필요한 정보를 담는 헤더
• entity headers: 바디의 길이 등과 같은 엔티티 바디에 대한 상세 정보를 포함하는 헤더.

body

request가 전송하는 데이터를 담고 있는 부분. 전송하는 데이터가 없다면 공백이 된다.

Response Message

구조는 request message와 동일하다.

HTTP 매서드

개념

클라-서버 간 요청과 응답이 이뤄지는 방식 → 서버가 수행해야 할 동작을 지정해 요청하는 방법이다. 리소스와 동작을 분리하여 서버가 수행할 동작을 지정해 주면서 URI에게는 리소스만 식별해도 되도록 할 수 있기 때문에 이런 매서드를 지정해서 사용한다.

메서드 종류

간단하게 하면 위의 표와 같다. 아래에 각각의 메서드에 대해 상세하게 서술해 보겠다.

GET

• 리소스를 조회하는 메서드. 서버에 전달하고 싶은 데이터는 query를 통해 전달.
  

• query: 쿼리 스트링 혹은 쿼리 파라미터라고 하며 URL에 ? 뒤에 요청하고자 하는 추가적인 정보를 붙이거나 query=”요청 key”와 같은 형태로 요청한다.

  → 바디를 이용해서도 전달 가능하지만 이와 같은 방법은 서버에서 따로 구현을 해야 지원 가능하기 때문에 구현 되지 않은 서버에서는 사용할 수 없다. 따라서 위의 쿼리로 하는 경우가 대부분이다.

  → 쿼리 스트링은 브라우저의 기록에도 남으며 클라이언트에게 전달되는 데이터가 노출되어있기에 보안 상 유의가 필요하다.
  

• POST로도 조회가 가능하지만 GET은 캐싱이 가능하기 때문에 GET을 사용하는 것이 더 유리하다.

• 예시

  • URL 입력, 링크 클릭이나 검색엔진의 검색과 같은 것에서도 사용한다.

• 특징: 멱등성(동일한 연산을 여러 번 수행해도 결과가 달라지지 않는 성질)이란 개념을 가지고 있어 여러번 조회 요청을 해도 리소스는 변하지 않는다.

POST

• 요청 데이터를 처리하는 메서드. 메시지 바디를 통해 서버로 요청 데이터를 전달, 서버는 바디를 읽어 들어온 데이터를 처리하여 응답한다.
  • GET 메서드를 사용하는데 JSON으로 조회한 데이터를 넘겨야 하는 경우와 같이 query로 처리하기 어려운 것들은 POST를 사용한다.
• 단순히 데이터를 생성하거나 값을 변경하는 것을 넘어 프로세스의 상태가 변경되는 경우(시스템에 큰 변화가 생기는 경우)에 사용한다. → 이때 꼭 새로운 리소스가 생기지 않아도 된다.
  
• 특징
  • 주로 신규 리소스 등록과 프로세스 터리에 사용한다.
  • body에 데이터를 담아 전송하므로 메시지 길이에 제한이 없다.
    • 데이터는 key - value 형식으로 이뤄져있다 (”name”: “김양치”)
  • JSON 뿐만 아니라 문자열, Button과 같은 객체들의 값도 전송 가능하다.
  • GET과 비교했을 때 데이터가 body에 있어 외부에 노출되지 않아 보안상 이점이 있다.
  • POST로 조회가 가능하지만 GET과 달리 멱등성을 지니지 않아서 수행마다 결과가 다를 수 있다. 또한 GET이 캐싱 기능을 사용해 GET의 조회 속도가 더 빠르다.

PUT

• 리소스를 덮어쓰기 혹은 생성을 하는 메서드이다.
  • POST와 다르게 클라이언트가 리소스 위치를 알고 URI를 지정해 요청한다. → POST와 PUT의 그림 예시를 비교해보면 POST는 users에서 정보를 요청하고 서버는 그곳 내에서 정보를 찾아 제공. PUT은 정보가 있는 정확한 위치를 users/10과 같이 정확히 지정해 사용.
    
• 특징
  • 리소스를 완전히 대체한다.
  • 클라이언트가 리소스를 식별 할 수 있다. (정확한 위치를 사용하기 때문. )
  • 하나의 URI 안에 있는 데이터 전체를 건드리기 때문에 부분 수정이 불가능하다. → 데이터 수정 시 기존의 데이터의 일부를 변경하고 싶다면 수정되지 않는 부분도 body 안에 넣어야만 데이터가 사라지지 않는다.
  • 덮어쓰거나 생성하는 것 모두 그 위치에 동일한 데이터를 저장하게 되는 것이므로 멱등성을 띈다.

PATCH

• 리소스의 부분변경을 하는 메서드.
• 이 메서드를 지원하지 않는 경우도 있다
  • 이럴 땐 POST를 사용한다. 이때 변경하지 않는 데이터가 덮어쓰기로 사라지는 것을 주의해야 한다.
• 멱등성을 띄지 않는다.

DELETE

• 요청받은 리소스를 제거한다.
• 제거할 리소스가 없다면 그대로 종료된다.
  • 상태코드
    • 제거할 수 있는것 같은데 아직 미시행: 202
    • 제거했고 더이상 정보가 없다: 204
    • 제거 후 상태를 설명한다: 200
• 데이터가 있으면 제거하고 없으면 그대로 두니 리소스의 상태가 항상 동일한 멱등성을 띈다.

HEAD

• GET과 동일하지만 body를 반환하지 않는다. 단순히 리소스의 유무만 체크한다.
• 서버의 응답 헤더를 보고 리소스의 수정 여부를 파악 가능하다.

OPTIONS

• 예비 요청에 사용하는 메서드
  • 예비요청: 본 요청을 하기 전에 해당 서버가 지원하는 메서드 등을 확인할 수 있는 요청이다.
  • 요청시 특정 위치를 입력하거나 *를 이용해 전체에 대한 요청도 가능하다. (예시 그림도 전체에 대한 요청을 한 모습이다. )

CONNECT

• 요청한 리소스에 대해 양방향 연결을 시작하는 메서드.
  • 터널을 열기 위해 사용할 수 있다. → SSL을 사용하는 웹사이트에 접속할 때 활용 가능. SSL은 핸드셰이킹을 하며 암호화 키를 서버로부터 받으므로 양방향 통신이 필요하기 때문이다.
    
• CONNECT는 홉바이홉(IP를 사용한 통신) 메서드이다.
• TRACE
  • 주로 통신에 대한 진단 목적으로 사용된다.
  • 해당 메서드가 서버로 전송되면 서버에서는 요청을 그대로 응답 본문으로 반환한다(루프백 한다). 이를 통새 어떤 변경이나 추가가 이뤄지는지 확인 가능하다. → 디버깅에 활용 할 수 있다.

HTTP 메서드의 속성

메서드 별로 하는 역할이 다르기도 하고 서로 겹치기도 한다. 그런 메서드들 사이에서도 공통된 부분들이 있는데 그것을 속성으로 묶을 수 있다. 이런 속성에는 크게 3가지가 있다.

• Safe(안전)
  • 메서드를 사용해도 리소스의 변화가 없음을 나타낸다
  • 조회 기능의 GET과 HEAD, 예비 요청의 OPTIONS, 통신 진단의 TRACE가 있다.
• Idempotent(멱등)
  • 위에서 설명했던 멱등성이 바로 이것이다. 해당 메서드를 사용한 요청을 여러번 수행해도 늘 같은 결과를 반환하는 메서드들을 말한다.
  • 리소스를 건드리지 않는 Safe 특성을 가진 메서드들과 더불어 덮어쓰기&생성의 PUT, 리소스 제거의 DELETE가 해당된다.
    • 이때 POST를 이 속성으로 헷갈릴 수 있는데 POST는 프로세스를 변화 시키는 것으로 변화 후 재실행 시 결과값이 달라질 가능성이 있어 멱등성에 해당하지 않는다.
• Cacheable(캐시 가능)
  • 응답 결과를 서버에 캐싱해서 사용 가능한 메서드들의 속성이다.
  • GET, HEAD, POST, PATCH 가 가능하다
    • POST와 PATCH는 body의 내용까지 캐시 키에 들어가야 하기에 구현이 어렵다. → 실제로는 GET과 HEAD정도만 캐시를 사용한다.

위의 속성들을 정리한 표이다. 이 표에는 속성 3가지 이외에 Request와 Response의 바디에 내용이 있는지도 체크가 되어있다.

---

정리

• HTTP의 기본적 구조인 Startline, Headers, Body에 대해 공부했다.
• 메서드는 서버와 클라이언트가 통신하는 수단인 메시지가 서버에게 행동을 지정하는 문구이며 이 문구는 조회의 GET과 HEAD, 등록과 요청의 POST, 생성과 덮어쓰기의 PUT, 부분 변경의 PATCH, 삭제의 DELETE, 예비 요청 및 통신 옵션의 OPTIONS, 양방향 통신과 SSL의 CONNECT, 루프백과 디버깅의 TRACE를 공부했다.
• 메서드들의 공통점에 해당하는 속성 안전, 멱등, 캐시가능에 대해 구분하고 추가적으로 바디의 유무도 확인하였다.