메세지를 통해서 클라이언트는 요청을 보내고 서버는 응답을 하는 구조이다.
서버에는 데이터와 로직을 집중하고 클라이언트에는 URI와 사용성을 증가시키기위함이다.
=> 각각 독립적인 발전이 가능해졌다.(프론트와 백)
서버가 클라이언트의 상태를 보존하지 않는다. 서버는 클라이언트를 식별할 수가 없다는 뜻이고 상태를 보존하지 않는다라는 말은 데이터를 주고 받기 위한 데이터 요청이 독립적이라는 것입니다. 다른 말로 이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다는 말입니다.
특징
-별도의 세션 추가 정보를 관리하지 않아도 된다.
-갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
-무상태는 응답 서버를 쉽게 바꿀 수 있다.
-아무 서버나 호출해도 된다.
-수평 확장에 유리하다.
-한 번 통신에 많은 데이터량이 통신된다.
but 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
ex)
무상태: 로그인 인터페이스가 나오는 화면
상태유지: 로그인한 상태를 서버를 계속 유지
참고
-상태 유지를 위해서 쿠키와 세션을 사용한다. HTTP헤더 부분 참고(세션은 서버 쿠키는 브라우저, 클라이언트)
http는 클라이언트와 서버가 연결을 맺은 후, 서버가 응답을 마치면 맺었던 연결을 바로 종료한다.
웹 특성상 동시에 많은 사람이 서비스를 이용해도 실제 처리하는 작업은 적은데 이 때 연결을 계속 유지한다면 많은 리소스 발생
=> 이러한 웹 특성을 고려하여 기본적으로 Http는 연결을 유지하지 않는 모델로 설계 됨
=> http는 서버 리소스을 매우 효율적으로 사용한다.
ex) 검색 작업
비지속연결 HTTP
HTML뿐만 아니라 JS, CSS, Image등 수 많은 자원을 다운로드할 때마다 연결/종료를 해야함 => 시간추가
그 뿐만 아니라 자원마다 TCP/IP 연결을 새로 맺어야함 => 시간추가
지속연결 HTTP
맨 처음 TCP/IP 연결을 유지하고 나머지 자원에 대해서 클라이언트/서버가 요청/응답하는 것이다. <= 현재 사용 중
=> HTTP 2.0 3.0에서 더 많은 최적화가 이루어지고 있음
요청메세지 start-line = request-line
method SP request-target sp HTTP-version CRLF
method: HTTP 메서드
request-target: absolute=path[?query]절대경로[?쿼리]
HTTP-version: HTTP-버전
SP: space
CRLF: enter
응답메세지 start-line = status-line
HTTP-version SP status-code SP reason-phrase CRLF
HTTP-version: HTTP-버전
status-code: HTTP 상태 코드
reason-pharase: 상태코드를 사람이 이해할 수 있는 설명 글
header-field = field-name ":"OWS field-valu OWS
OWS: 띄어쓰기 허용
ex)
Host: www.google.com
Content-Type: text/html;charset=UTF-8
헤더는 HTTP전송에 필요한 모든 부가정보를 담고 있음
실제 전송할 데이터
URI설계
=>uri는 리소스만 식별
메소드는 행위만 식별
ex)
-리소스 회원(명사)
-조회 들록 삭제 변경 행위(동사)
리소스를 조회한다. 서버에 전달하고 싶은 데이터는 query(퀴리)를 통해서 전달한다.
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
참고: 검색에서 사용, 보안이 요구되지 않을 때, 적은양의 데이터를 보낼때
요청 데이터를 서버로 전달한다. 서버는 메세지 바디를 통해 들어온 데이터를 처리한다. 데이터가 변경되거나 신규 리소스 등록, 프로세스가 진행되는 등 많은 상황에서 POST를 사용한다. 중요한 부분은 데이터를 생성, 처리할 뿐 아니라 프로세스를 처리하는 데에 있다.
ex)
1 HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
2 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
3 서버가 아직 식별하지 않은 새 리소스 생성
4 기존 자원에 데이터 추가
다른 메서드로 처리하기 애매한 경우도 종종 사용한다.
POST는 리소스가 고유한 체계에 따라서 처리하도록 요청한다.
POST /members HTTP/1.1
이와 같이 보내면 서버는 정해진 체계에 따라서 프로세스에 사용하거나 등록에 사용한다.
예를 들어 회원을 등록할려고 하면
/members => /members/100
서버는 자신의 고유한 체계에 따라서 신규 리소스를 생성하고(100처럼) JSON과 같은 파일을 생성한다. 이후 응답데이터를 클라이언트로 보낸다.
참고: 보안이 요구될 때, 많은 양의 데이터를 보낼때
쉽게 설명해서 ctrl + v와 같다. 리소스를 완전히 대체한다. 리소스가 있으면 대체하고, 없으면 새로 생성한다.
POST와 다른 점은 클라이언트가 리소스를 식별한다는 점이다. 클라이언트가 리소스 위치를 알고 URI를 지정한다.
PUT /members/100 HTTP/1.1 (POST와 차이점)
"리소스를 완전히 대체한다"
리소스를 수정한다는 것이 아니다.
/members/100 (기존)
{
"username": "park",
"age": 20
}
PUT /members/100 HTTP/1.1
/members/100 (전송)
{
"age": 50
}
/members/100 (대체)
{
"age": 50
}
리소스를 수정하고 싶으면 PATCH를 사용하면 된다.
리소스를 제거하고 싶으면 DELETE를 사용하면 된다.
GET과 HEAD는 호출해도 리소스를 변경하지 않는다
동일한 요청을 여러 번 보내도 한 번 보내는 것과 같은 것
동일한 사용자가 동일한 행위에 대해서 멱등인 것이다
올바르게 구현한 GET, PUT, DELETE 메소드는 멱등성을 지녀야 한다.
POST는 멱등이 아니다.
응답 결과 리소스를 캐시해서 사용해도 되는가?
GET, HEAD, POST, PATCH 캐시가능
실제로는 GET, HEAD정도만 캐시로 사용
POST, PATCH는 본문 내용까지 캐시 키로 고려해야하는데, 구현이 쉽지 않음
쿼리 파라미터를 통한 전송
-GET: 주로 정렬 필터
메세지 바디를 통한 데이터 전송
-POST PUT PATCH: 회원가입 상품주문 리소스 등록 리소스 변경
Form 양식에 따라 HTTP를 생성하여 전송한다.
주로 회원가입, 상품 주문, 데이터 변경 사용
< input type="file"> 이 존재하는 경우
HTML =>
form에 enctype="multipart/form-data" 사용
HTTP 헤더 =>
Content-Type 속성이 multipart/form-data; boundary=---XXX로 지정(자동)
정해진 형식에 따라 메세지를 인코딩 하기 위해서이다. 처리하기 위한 서버는 멀티파트 메세지에 대해서 분리하여 개별(boundary=---XXX) 파일의 정보를 얻음
참고: HTML Form전송은 GET, POST만 지원
form 양식 없이 데이터를 바로 전송하는 경우
-서버 to 서버
-앱클라이언트
-웹클라이언트
ex)HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용 (AJAX)
-POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송
-GET: 조회, 쿼리 파라미터로 데이터 전달
Content-Type: application/json 주로 사용 (사실상 표준)