✏️ HTTP

Ji Yun·2023년 3월 19일

http

스프링

목록 보기

2/3

출처

HTTP

모든 것이 HTTP
HTML, text, image, 음성, 영상, 파일, JSON 등 거의 모든 형태 데이터 전송 가능
TCP/IP 통신에 추가적인 헤더를 붙인 응용 프로토콜
특징 : 클라이언트-서버 구조, stateless, 비연결성
☑️ request-response 구조 : TCP 기반이므로 당연함
☑️ stateless : 서버가 클라이언트의 상태를 보존하지 않음
➡️ 따라서 서버 확장성이 높다. 즉, 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다(어떤 서버가 요청을 받아도 응답할 수 있기 때문에).
➡️ 반면에 클라이언트가 요청마다 전달해야할 데이터가 늘어난다(매번 새로운 서버에게 요청을 하므로).
☑️ 비 연결성 : HTTP는 기본이 연결을 유지하지 않는 모델.

TCP 연결 -> http 응답 주고받음 -> TCP 종료신호 주고 받음
따라서 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하이다(서버 자원을 효율적으로 사용 가능).
✅ 하지만 요청이 끝날때마다 TCP/IP 연결까지 끝나므로 새로 맺을 때마다 시간이 소요된다. 이 문제는 HTTP 지속 연결로 해결한다 (종료 신호를 고의적으로 늦춰 연결이 지속되는 것처럼 동작)

HTTP 메세지

1. HTTP 요청 메세지

start-line(request line) = method SP request-target SP HTTP-version CRLF
➡️ HTTP 메소드 + 요청대상(경로+쿼리파라미터) + HTTP 버전
header-field = field-name ":" OWS field-value OWS
메세지 바디

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

2. HTTP 응답 메세지

start-line(status-line) = HTTP-version SP status-code SP reason-Phrase CRLF
HTTP 헤더 동일
HTTP 메세지 바디 ➡️ 실제 전송할 데이터 (HTML 문서, 이미지, 영상, JSON 등)

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

HTTP 메소드

API URI 설계에 대해 알아보자
좋은 URI 설계는 리소스를 식별하는데에 있다.
정리하면, API를 리소스와 리소스를 대상으로 하는 행위로 분리하고 URI는 리소스 식별만 한다
회원 정보 관리 API 5가지에 대해 URI를 설계한다고 해보자

회원 목록 조회
회원 조회
회원 등록
회원 수정
회원 삭제

등이 있을 것이다. 이 때 URI를 /read-member-list , /create-member 등으로 설계하는 것이 대부분인데 이는 좋지 않다. 이 API에서 리소스는 회원이다
URI는 '회원'이라는 리소스만 식별하면 되므로 /member 만을 URI에 매핑한다
그럼 다 똑같은 URI에 대해 어떤 행위를 해야할지 어떻게 구분할까? 이것이 바로 HTTP 메소드이다.

1. GET 메소드

리소스 조회 요청
요청 메세지의 query를 통해 데이터 전달
ex) GET /members/100 HTTP/1.1 ➡️ 100번 회원에 대한 정보 조회를 요청

2. POST 메소드

데이터 처리 요청 (아주 다양)
메시지 바디를 통해 데이터 전달 (서버에서 모든 처리 기능 수행)
query에 구체 리소스 경로 없음
요청 데이터 처리 종류 예시
1. 새 리소스 생성 및 등록, 기존 자원에 데이터 추가
2. 프로세스를 처리해야 하는 경우 (HTML폼에 입력한 정보로 회원 가입, 주문 등)
  ex) 주문 -> 결제완료 -> 배달 시작 -> 배달 완료 프로세스 상태 변경
3. 다른 메소드로 처리 애매한 경우 (그러나 최대한 해당 메소드로 요청해야 함)

3. PUT 메소드

서버에 리소스가 있으면 완전히 대체, 없으면 생성
클라이언트가 구체 리소스 경로를 알고 있다

4. PATCH 메소드

리소스 부분 변경

5. DELETE 메소드

리소스 삭제

HTTP methode의 이용

클라이언트에서 서버로 데이터를 전송할 때 이용한다
전달 방식 1. 쿼리 파라미터를 통한 데이터 전송 (GET) - 검색
전달 방식 2. 메시지 바디를 통한 데이터 전송 (POST, PUT, PATCH) - 회원 가입, 리소스 등록 및 변경

4가지 상황

정적 데이터 조회 ➡️ 이미지, 정적 텍스트 문서
- GET 메소드 사용
- 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로(ex: /static/star.jpg)로 단순한 조회
동적 데이터 조회 ➡️ 검색, 게시판 목록의 정렬 필터
- GET 메소드
- 쿼리 파라미터 사용 (서버는 쿼리 파라미터를 기반으로 정렬 필터해서 결과를 동적으로 생성)
HTML form 을 통한 데이터 전송 ➡️ 회원 가입, 주문, 변경
- GET 과 POST만 지원
- HTML Form submit 시에 POST 메소드 사용
- 기본 content-type: application/x-www-form-urlencoded
  ➡️ POST이므로 메세지 바디에 담아 보내는데 그 형식이 query 파라미터와 동일함(key=value)
- 바이너리 데이터 전송 content-type: multipart/form-data

HTTP API를 통한 데이터 전송 (HTML 폼을 이용하지 않는 거의 모든 상황) ➡️ 회원 가입, 주문, 변경 + 서버끼리의 데이터 전송
- 서버 to 서버, 앱 클라이언트, 웹 클라이언트 ➡️ HTML에서 form 대신 자바 스크립트를 통한 통신에서 사용
- PUT, PATCH 이용 가능
- 거의 모든 content-type: application/json