[HTTP 기본지식]-(2)

HTTP

• 모든 것이 HTTP (Hyper Text Transfer Protocol)
• HTML, 이미지, 영상, 파일 모든 형태의 데이터 전송 가능
• TCP 직접 연결은 매우 드문 경우
• 1.1버전 현재 많이 사용하고 가장 중요하다. (RFC 7230~7235 버전)
• 2, 3 버전은 성능개선에 초점이 맞춰져있음
• HTTP /1.1, HTTP/2 → TCP 기반
• HTTP/3 → UDP 기반
• HTTP 버전확인 → 개발자 도구 → 네트워크 →마우스 오른쪽 → protocol (h2→ HTTP/2, h3→ HTTP/3)
• 클라이언트 - 서버 구조 : 클라이언트는 서버에 요청을 보내고 서버는 요청에 대한 결과를 클라이언트에게 보낸다. → 양쪽이 독립적으로 발전할수 있다 (중요)
• 무상태 프로토콜(stateless) : 서버가 클라이언트의 상태를 보존하지 않는다.
  • stateful : 상태유지 , 문맥 보존 , 응답서버를 쉽게 바꿀 수 없음 같은 서버가 항상 유지되어야한다. 통신중 서버에 에러가나면 통신을 처음부터 다시해야함
  • stateless : 상태를 유지하지 않음, 응답 서버를 쉽게 바꿀 수 있음, 클라이언트 요청이 증가해도 서버를 대거 투입가능(수평확장 scale-out)
    • 한계: 상태유지가 필요한 경우가 있다. (ex 로그인 상태유지 → 브라우저 쿠키 + 서버 세션 ), 데이터를 너무 많이보낸다.
    • 최대한 stateless로 설계하고 예외의 경우 stateful로 설계
• 비연결성 (connectionless) : 요청, 응답 후 연결을 끊음 → 최소한의 자원만을 사용할 수 있다, 여러 클라이언트의 요청을 받을 수 있다.
  • 단점 : TCP/IP 연결을 새로 맺어야한다. - 연결 시간 소모
• HTTP 메시지를 통해 통신
  • HTTP 요청 메세지 : 시작라인(HTTP method, path,HTTP 버전), 헤더(host), 공백라인,(메시지 바디)
  • HTTP 응답 메세지 : 시작 라인(HTTP 버전, HTTP status), 헤더(content-type...), 공백라인(CRLF), 메세지 바디(html)
• 시작라인(start-line) : request-line, status-line
  • 요청메시지request-line : method SP(SPACE) request-target SP(path) HTTP_version CRLF(엔터)
    • HTTP method : GET(서버에 리소스 요청), POST(서버에 데이터 전송후 처리요청), PUT, DELETE
    • 절대경로[?쿼리] : “/”로 시작하는 경로
    • HTTP-version
  • 응답메세지 status-line :
    • HTTP 상태코드 : 200 성공 400 클라이언트 요청오류 500 서버 내부 오류
• 헤더
  • HTTP 전송에 필요한 모든 부가정보
  • 메시지 바디의 내용, 크기, 압축여부, 브라우저 정보, 인증정보, 캐시관리 정보 등... 메시지 바디 제외 필요한 모든 메타정보가 다 들어있다.
  • 임의의 헤더 추가시 약속된 클라이언트, 서버만 파악 가능
• 메시지 바디
  • 실제 전송할 데이터가 들어있음 json, html, 이미지 등

HTTP 메서드

• URI 설계에서 가장 중요한 것은 리소스 식별이다.
• 리소스와 행위를 분리 → 리소스 : 목적어, 행위: 동사
• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 일부 변경
• DELETE : 리소스 삭제
• HEAD : GET과 동일하지만 메세지바디 제외 헤더 만 요청
• OPTIONS, CONNECT,TRACE ... 생각보다 다양하다

GET

• 서버에 전달하고 싶은 데이터는 쿼리를 통해 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 실무에서는 메시지 바디 사용하지 않음 지원하지 않는 서버가 많기 때문이다.
• 조회할 때는 GET 사용하는게 유리, 캐싱이 가능하다. POST는 캐싱이 어려움

POST

• 주로 신규 데이터 등록, 변경된 프로세스 수정에 사용
• 신규 생성시 응답 데이터 (201 CREATED, Location : path, 등록된 데이터)
• 사용 예시 : 회원가입, 게시판 글쓰기, 댓글달기, 신규 주문 생성, 기존 데이터 수정
• 프로세스를 처리하는 경우에 사용 - 다음 데이터 프로세스를 처리하는 단계에서 사용한다.
• POST의 결과로 새로운 리소스가 생성되지 않는 경우도 있다.
• 컨트롤 URI(동사형 URI)를 사용하기도 한다.
• 다른 메서드로 처리하기 애매한 경우 (GET 메서드에 메시지 바디를 넣고싶은데 서버에서 지원하지 않을 때)
• 애매하면 POST

PUT

• 생성 혹은 존재한다면 기존 파일 덮어쓰기
• 클라이언트가 리소스를 지정(식별)한다. - POST와의 차이
• 데이터 필드 가 작성되지않으면 그 데이터 모두 사라짐→ 완전 대체

PATCH

• 리소스 부분 변경
• 데이터 필드 작성 안 해도 기존의 데이터 필드가 존재하면 유지
• 지원 안되는 서버일경우 POST

HTTP 메서드 속성

• 안전 : 호출시 변경발생 안함
• 멱등(Idempotent) : 한번 호출하든 n번 호출하든 결과가 같다. (Y) GET,PUT,DELETE /(N) POST
• 멱등 활용하는 이유 : 서버가 오류났을 때 클라이언트가 같은 요청을 다시 해도 결과가 같길 원할 때
• 외부요인으로 리소스가 변경될 때 다른 결과값이 나오는 것은 멱등의 판단 기준에 들어가지 않는다.
• 캐시가능 Cacheable : 실제는 GET(url만 잡으면 됨), HEAD만 캐시 사용 POST, PATCH는 본문 내용까지 캐시키로 고려해야해서 구현 어려움

HTTP 메서드 활용

• 클라이언트에서 서버로 데이터 전송
  • 쿼리 파라미터 → GET, 주로 정렬필터(검색어)
  • 메시지 바디→ POST, PUT, PATCH 회원가입, 상품주문, 리소스 등록, 리소스 변경
  • 상황
    1. 정적데이터 조회- 추가데이터 전달 없음(쿼리 파라미터 없음). URL 경로만 전송, 이미지, 정적 텍스트 문서
    2. 동적 데이터 조회- 데이터 전달함, 쿼리 파라미터에 따라 결과가 동적으로 생성된다. 검색, 게시판 목록 조회 GET
    3. HTML Form을 통한 데이터 전송
       1. POST : Form 태그내부의 input box에 데이터를 입력하면 입력한대로 데이터가 전송됨.(Content-Type : application/x-www-from-urlencoded) POST
       2. GET : Form 태그 내부의 데이터를 쿼리 파라미터로 보냄
       3. enctype = ”multipart/form-data” Content-Type=multipart/form-data;boundary=—XXX, boundary가 각 데이터를 구분함, 주로 파일 업로드에 사용
    4. HTTP API를 통한 데이터 전송
       1. 서버에서 서버로 통신할때 사용, 아이폰, 안드로이드에서 전송할때 주로 사용
       2. Form대신에 자바스크립트를 통한 통신에 사용한다.
       3. POST, PUT, PATCH : 메시지 바디로 데이터 전송
       4. GET : 쿼리 파라미터로 데이터 전송
       5. Content-Type : application/json 을 주로 사용 (사실상 표준)
• HTTP API 설계 예시