카라멜마끼아또

개인 공부를 위한 공간입니다
상업적 용도로 활용되지 않습니다

HTTP?

Hypertext Transfer Protocol

하이퍼텍스트 전달하는 프로토콜

HTML과 같은 리소스를 가져올 수 있도록 해주는 프로토콜

 

웹에서 이루어지는 모든 데이터 교환의 기초

클라이언트-서버 프로토콜

 

 

클라이언트와 서버들은 개별적인 메시지 교환에 의해 통신

클라이언트가 보내는 메시지 :: Request

서버의 응답 메시지 :: Response

 

 

어플리케이션 계층 프로토콜

신뢰 가능한 전송 프로토콜이라면 이론상 무엇이든 사용 가능

보통은 TCP, TLS(암호화된 TCP)를 통해 전송

 

확장성 덕분에 하이퍼텍스트 문서 뿐만 아니라 이미지, 비디오, HTML폼 결과를 서버로 POST하기 위해서 사용하기도 함

.

클라이언트의 개별적인 요청들은 서버로 전송

서버는 요청을 처리하고 Response라는 응답 전송

Request와 Response사이에는 여러 개체가 존재 (Proxy같은)

 

 

HTTP 작동방식

클라이언트

서버에게 요청을 보내는 리소스 사용자

웹 브라우저, 모바일 어플리케이션, IoT 등

 

서버

클라이언트에게 요청에 대한 응답을 제공하는 리소스 관리자

 

 

Proxy

웹 브라우저와 서버 사이에는 수많은 컴퓨터와 머신이 HTTP메시지를 이어받고 전달

이러한 컴퓨터, 머신들 중 어플리케이션 계층에서 동작하는 것들을 일반적으로 Proxy라고 호칭

 

• 캐싱 (브라우저 캐시 등)
• 필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단 등)
• 로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)
• 인증 (다양한 리소스에 대한 접근 제어)
• 로깅 (이력 정보 저장)

 

 

HTTP 메시지

Request

요청 메시지

Method : HTTP 요청 메소드 (GET, POST 등)

Path : 가져오려는 요청 메시지의 경로

           (프로토콜 http://, 도메인 developer.mozilla.org, TCP포트 80) 등을 제거한 리소스 URL

Version of the protocol : 프로토콜의 버전 (HTTP/1.1)

Headers : 서버에 대한 추가 정보를 전달 (리소스 요청 경로 등)

 

Response

응답 메시지

Version of the protocol : 프로토콜 버전 (HTTP/1.1)

Status Code : 요청의 성공 여부, 그 이유를 나타내는 상태 코드 (200 성공)

Status Message : 상태코드의 짧은 설명

Header : Request 메시지의 헤더와 마찬가지로 메시지에 대한 정보

 

 

 

 

HTTP 메소드

• GET : 서버로부터 데이터 취득
• POST : 서버에 데이터를 추가, 작성
• PUT : 서버의 데이터 갱신 (전체 갱신)
• PATCH : 리소스의 데이터 갱신 (일부분 갱신)
• DELETE : 서버의 데이터 삭제
• HEAD : 서버 리소스의 헤더 (메타 데이터 취득)
• OPTIONS : 리소스가 지원하고 있는 메소드의 취득
• CONNECT : Proxy 동작의 터널 접속 변경

 

 

GET

주로 데이터를 읽거나(Read) 검색(Retrieve)할때 사용되는 메소드

GET요청이 성공적으로 이루어진다면 XML이나 JSON과 함께 200(OK) HTTP응답 코드 리턴

에러 발생시 에러 코드 리턴 (404, 400, 500 등)

 

- HTTP 명세에 의하면 GET은 오로지 데이터를 읽을때만 사용

- 멱등성 O 

- 데이터를 변경하는 연산에 사용 X

 

 

** 멱등성?

Idempotence

여러번 수행해도 같은 결과를 반환하는 것

호출로 인해 데이터가 변형되지 않는다는 것을 의미

 

Ex)

GET / User/1

조회이기 때문에 요청 시, Body와 Content-Type이 비워져 있음

조회할 데이터에 대한 정보는 URL을 통해 파라메터를 전달

조회 성공 시 Body값에 데이터 값을 저장하여 성공 응답 리턴

 

!! GET은 캐싱이 가능하여 같은 데이터를 여러 번 조회할 경우 저장한 값을 사용하여 조회 속도 향상 !!

 

 

POST

새로운 리소스를 생성(Create)할때 사용

정확히는 하위 리소스(부모 리소스의 하위 리소스)들을 생성하는데 사용

성공적으로 생성되면 201 (Created) HTTP 응답 리턴

 

- 멱등성X

- 같은 요청 반복했을 때, 항상 같은 결과물이 나오지 않기 때문

- 같은 POST 두번 보내면 같은 정보를 담은 두개의 다른 Resource를 반환할 가능성 높음

 

Ex)

POST /user
body : {date : "example"}
Content-Type : "application/json"

데이터 생성을 위해 Body, Content-Type 지정 필요

URL이 아닌 Body를 통해 값 전달받음

데이터 조회 성공 시 Body 값에 저장된 데이터 값을 저장하고 성공 응답 리턴

 

 

PUT

리소스 생성/업데이트를 위해 사용

 

- 멱등성 O

- 동일한 PUT요청 여러번 하면 항상 동일한 결과 생성

 

Ex)

PUT /user/1
body : {date : "update example"}
Content-Type : "application/json"

 데이터 수정 위해 Body, Content-Type 필요

URL을 통해 수정할 데이터를 조회하기 위한 Parameter 전송

Body에 수정할 데이터 값 담아 전송

데이터 조회 성공 시 Body 값에 저장된 데이터 값을 수정하여 성공 응답 리턴

 

 

PATCH

PUT과 마찬가지로 리소스를 수정할때 사용

 

- PUT과 달리 데이터의 일부분만 수정

- 멱등성 X

 

Ex)

PATCH /user/1
body : {date : "update example"}
Content-Type : "application/json"

 데이터 수정 위해 Body, Content-Type 필요

URL을 통해 수정할 데이터를 조회하기 위한 Parameter 전송

Body에 수정할 데이터 값 담아 전송

데이터 조회 성공 시 Body 값에 저장된 데이터 값을 수정하여 성공 응답 리턴

 

DELETE

리소스 삭제를 위해 사용

 

Ex)

DELETE /user/1

조회와 마찬가지로 Body, Content-Type 불필요 (삭제만 하기 때문)

URL통해 삭제할 데이터를 조회하기 위한 Parameter 전송

데이터 삭제 성공 시 Body값 없이 성공 응답만 리턴

 

 

 

기타

 

URL에 데이터 정보가 없기 때문에  POST 방식이 GET보다 보안 관점에서 좋음

 

POST와 PUT은 구분해서 사용

POST는 새로운 데이터를 계속해서 생성하지만, PUT은 같은 요청 계속하더라도 데이터가 계속 생성되지 않음