New 병아리 개발자

# HTTP 메서드 활용

## 클라이언트에서 서버로 데이터 전송

데이터 전달 방식은 크게 2가지

1. 쿼리 파라미터를 통한 데이터 전송

• 주로 GET, 정렬 필터(검색어) 에서 사용.

2. 메시지 바디를 통한 데이터 전송

• POST, PUT, PATCH 등
• 회원가입, 상품 주문,리소스 등록, 리소스 변경 등에 사용.

클라이언트에서 서버로 데이터 전송

1. 정적 데이터 조회

• 이미지, 정적 텍스트 문서 등 조회는 GET 사용.
• 정적 데이터는 일반적으로 쿼리 파라미터 없이, 리소스 경로로 단순하게 조회 가능.

2. 동적 데이터 조회

• 쿼리 파라미터 사용.(GET /search?q=hello&hl=ko)
• 주로 검색, 게시판 목록에서 정렬 필터(검색어)에 사용.
• 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용.
• 조회는 GET 사용. (GET은 쿼리 파라미터를 사용해 데이터를 전달)

3. HTML Form 을 이용한 데이터 전송

• POST 전송 - 저장
• HTML Form submit 시 POST 전송. (회원가입, 상품주문, 데이터 변경 등에 사용)
• Content-Type : application/x-www-form-rulencoded 사용.

form 의 내용을 메시지 바디를 통해 전송(key=value, 쿼리 파라미터 형식)

전송 데이터를 url encoding 처리 
예) aaa김 -> aaa%EA%B9%80

• HTML Form은 GET 전송도 가능 (하지만 저장 등에는 POST 사용)
• Content-Type : multipart/form-data

파일 업로드 같은 바이너리 데이터 전송 시 사용.

다른 종류의 여러파일과 폼 내용을 함께전송 가능 (그래서 이름이 multipart)

• 참고사항 : HTML Form 전송은 GET, POST만 지원.

4. HTTP API 전송

• 서버 to 서버로 백엔드 시스템 통신 시 사용.
• 앱 클라이언트에서 전송 시에도 사용 (안드로이드, 아이폰)
• 웹 클라이언트 : HTML에서 Form 전송 대시 자바 스크립트를 통한통신에 사용 (AJAX 통신) - 예) React, VueJs 같은 웹 클라이언트와 API 통신
• 메시지 바디를 통한 데이터 전송 (POST / PUT / PATCH)
• GET : 조회, 쿼리 파라미터를 데이터로 전달
• Content-Type : application/json을 주로 사용 (사실상 표준) - TEXT, XML(과거에 많이 사용), JSON 등등

## HTTP API 설계 예시

1. HTTP API (컬렉션)

• POST 기반 등록
• 예 : 회원 관리 API 제공

회원 관리 시스템 (POST 기반 등록 - 컬렉션) : 대부분의 실무에서 사용.

• API 설계 - POST 기반 등록.

회원 목록 : /members -> GET

회원 등록 : /members -> POST

회원 조회 : /members/{id} -> GET

회원 수정 : /members/{id} -> PATCH / PUT / POST
(PATCH : 부분 수정 / PUT : 완전히 덮어쓰기)
(PATCH 사용 권장, PUT은 게시판 수정 등에 사용)

회원 삭제 : /members/{id} -> DELETE

• POST - 신규 자원 등록 특징

클라이언트는 등록될 리소스의 URI를 모름. 
- 회원 등록 /members -> POST
- POST /members

서버가 새로 등록된리소스 URI를 생성해준다.
- HTTP/1.1 201 Created
  Location: /members/100


* 컬렉션 (Collection)
- 서버가 관리하는리소스디렉토리
- 서버가 리소스의URI를 생성하고 관리
- 여기서 컬렉션은 /members

2. HTTP API (스토어)

• PUT 기반 등록
• 예 : 정적 컨텐츠 관리, 원격 파일 관리

파일 관리 시스템 (PUT 기반 등록 - 스토어)

• API 설계 - PUT 기반 등록

파일 목록 : /files -> GET

파일 조회 : /files/{filename} -> GET

파일 등록 : /files/{filename} -> PUT
(PUT : 없으면 새로 생성, 있으면 덮어쓰기)

파일 삭제 : /files/{filename} -> DELETE

파일 대량 등록 : /files -> POST

• PUT - 신규 자원 등록 특징

클라이언트가리소스 URI 를 알고 있어야 함
- 파일등록 : /files/{filename} -> PUT
- PUT /files/star.jpg

클라이언트가 직접 리소스의 URI를 지정한다.


* 스토어 (Store)
- 클라이언트가 관리하는 리소스 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- 여기서 스토어는 /files

3. HTML FORM 사용 (컨트롤 URI)

• HTML FORM은 GET, POST만 지원 (제약 존재)
• AJAX같은 기술을 사용해서해결 가능 -> 회원 API 참고.

회원 목록 : /members -> GET

회원 등록폼 : /members/new -> GET

회원 등록 : /members/new 또는 /members -> POST

회원 조회 : /members/{id} -> GET

회원 수정 폼 : /members/{id}/edit -> GET

회원 수정 : /members/{id}/edit 또는 /members/{id} -> POST

회원 삭제 : /members/{id}/delete ->POST


* 컨트롤 URI
- GET, POST 만 지원하므로 제약 존재.
- 제약을 해결하기 위해 동사로 된 리소스 경로 사용.
- POST의 /new, /edit, /delete 가 컨트롤 URI.
- HTTP 메서드로 해결하기 애매한 경우 사용 함 (HTTP API 포함)

정리.

• HTTP API - 컬렉션 : POST 기반 등록, 서버가 리소스 URI 결정.
• HTTP API - 스토어 : PUT 기반 등록, 클라이언트가 리소스 URI 결정.
• HTML FORM 사용 : 순수HTML + HTML FORM 사용, GET 과 POST 만 지원.

참고하면 좋은 URI설계 개념 (중요 팁!) 

• https://restfulapi.net/resource-naming/

1. 문서 (document)

• 단일 개념 (파일 하나, 객체 인스턴스, 데이터베이스 row)
• 예 : /members/100, files/star.jpg

2. 컬렉션(collection)

• 서버가관리하는 리소스 디렉터리
• 서버가 리소스의 URI를 생성, 관리
• 예 : /members

3. 스토어 (store)

• 클라이언트가 관리하는 자원 저장소
• 클라이언트가 리소스의 URI를 알고 관리
• 예 : /files

4. 컨트롤러(controller), 컨트롤 URI (최후의 수단)

• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동사를 직접 사용
• 예 : /members/{id}/delete

# HTTP 메서드

## HTTP API 생성

• 요구사항 : 회원 정보 관리 API 생성 (회원 목록 조회 / 회원 조회 / 회원 등록 / 회원 수정 / 회원 삭제)

API URI 설계 (Uniform Resource Identifier)

회원 목록 조회 : /read-member-list
회원 조회 : /read-member-by-id
회원 등록 : /create-member
회원 수정 : /update-member
회원 삭제 : /delete-member

• 과연, 이건 좋은 URI 설계일까?
• URI 설계의 가장 중요한 건 '리소스 식별' 이다.

리소스의 의미?

회원을 등록하고 수정하고 조회하는게 리소스가 아니다.

예를 들어미네랄을 캐라에서 리소스는 미네랄. (즉, 회원이라는 개념 자체가 바로 리소스)

리소스를 어떻게 식별?

회원을 등록하고 수정하고 조회하는 것을 모두 배제.

회원이라는 리소스만식별하면 됨. (회원 리소스를 URI에 매핑)

API URI 설계 (리소스 식별, URI 계층 구조 활용)

회원 목록 조회 : /members
회원 조회 : /member/{id}
회원 등록 : /members/{id}
회원 수정 : /members/{id}
회원 삭제 : /members/{id}

참고 : 계층 구조상 상위를 컬렉션으로 보고 복수 단어 사용 권장함.
(member -> members)

• 위와 같이 했을 때 문제 : 회원 조회 / 회원 등록 / 회원 수정 / 회원 삭제 구분을 어떻게 할지?....

리소스와 행위를 분리. (가장 중요한 것은 리소스를 식별하는 것)

URI는 리소스만 식별. (URI는 리소스를 판별할때 사용)

리소스와 해당 리소스를 대상으로 하는 행위를 분리.

리소스 : 회원

행위 : 조회 / 등록 / 삭제 / 변경

리소스는 명사, 행위는 동사(미네랄을 캐라)

• 그렇다면 행위(메서드)는 어떻게 구분?.. -> HTTP 메서드가 식별.

## HTTP 메서드 (GET, POST)

• GET : 리소스 조회
• POST : 요청 데이터 처리 (주로 등록에 사용)
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH  : 리소스 부분 변경
• DELETE : 리소스 삭제
• HEAD : GET 과 동이랗지만 메시지 부분을 제외, 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션 (메서드)을 설명 (주로 CORS에서 사용)
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

1. GET (리소스 조회)

서버에 전달하고 싶은 데이터는 query (쿼리 파라미터, 쿼리 스트링)를 통해 전달.

메시지바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아 권장하지 않음.

2. POST (요청 데이터 처리)

• 핵심 : 메시지 바디를 통해 서버로 요청 데이터 전달.
• 서버는 요청 데이터를 처리.
• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능 수행.
• 주 용도 : 주로 전달된 데이터로 신규 리소스 등록 / 프로세스 처리에 사용.
• 스팩 : POST 메스드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 쵸어 한다.

POST는 다음의 기능에 사용.
1. HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공.
- 예) HTML, FROM에 입력한 정보로 회원가입, 주문 등에 사용

2. 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시.
- 예) 게시판 글쓰기, 댓글 달기

3. 서버가아직 식별하지 않은 새 리소스 생성.
- 예) 신규 주문 생성

4. 기존 자원에 데이터 추가.
- 예) 한 문서 끝에 내용 추가하기 등

참고 : 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.
(정해진 것이 없다.)

• POST 정리

1. 새 리소스 생성(등록)
 서버가 아직 식별하지 않은 새 리소스 생성
 
2. 요청 데이터처리
- 단순히 데이터를 생성하거나, 변경하는 것을 넘어 프로세스를 처리해야 하는 경우
예) 주문에서 결제완료 > 배달시작 > 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
- POS의 결과로 새로운 리소스가 생성되지 않을 수도 있다.
예) POST/orders/{orderId}/start-delivery (컨트롤 URI)

3. 다른 메서드로처리하기 애매한 경우
- 애매하면 POST 사용
예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

3. PUT (리소스를 완전히 대체)

• 리소스가 있으면 '완전히' 대체, 리소스가 없으면 생성 (덮어쓰기)
• 주의 : 리소스를 '완전히' 대체한다. 
• 중요 : 클라이언트가 리소스를 식별. (클라이언트가 리소스 전체 위치를 알고 URI 지정 - POST와의 가장 큰 차이)

4. PATCH (리소스 부분 변경)

• 리소스를 부분적으로 변경할 때 사용. (PATCH 지원 안될 경우에는 POST 사용)

5. DELETE (리소스 제거)

• 리소스를 제거할 때 사용.

## HTTP 메서드의 속성

1. 안전 (Safe Methods)

• 호출해도 리소스를 변경하지 않는 것.
• 계속 호출해서 로그가 쌓여장애가 발생한다면? -> 안전은 해당 리소스만을 고려.
• 멱등 (Idempotent Methods)
• 몇 번을 호출해도 결과가 동일.

2. 멱등 메서드

GET : 여러번 조회해도 같은 결과 조회.

PUT : 결과를 대체. (같은 요청 여러번 해도 최종 결과는 동일)

DELETE : 결과를 삭제. (같은 요청 여러번 해도 삭제된 결과 동일)

POST : 멱등이 아님!!!!!!! 두 번 호출하면 같은결제가 중복해서 발생할 수 있다.

• 멱등 활용 : 자동 복구 메커니즘에 활용.
• 재 요청 중간에 다른 곳에서 리소스를변경해 버리면? -> 멱등은 외부 요인으로 중간에 리소스가 변경되는 것은 고려하지 않음.

3. 캐시가능 (Cacheable Methods)

• 응답 결과 리소스를 캐시해서 사용해도 되는지?
• GET / HEAD / POST / PATCH 에서 캐시 가능.
• 실제로는 GET / HEAD 정도만 캐시로 사용. (POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현 쉽지 않음)

# HTTP 기본

## HTTP (HyperText Transfer Protocol)

• HTTP 메시지에 모든 것을 전송.
• (HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML (API) 등 거의 모든 형태의 데이터 전송 가능.
• 서버간에 데이터를 주고 받을때에도 대부분 HTTP 사용.
• HTTP/1.1 : 1997년, 가장 많이 사용. (우리에게 가장 중요한 버전)

기반 프로토콜

• TCP : HTTP/1.1, HTTP/2
• UDP : HTTP/3
• 현재 HTTP/1.1를 주로 사용

## HTTP 특징

• 클라이언트 서버 구조로 동작.
• 무상태 프로토콜(스테이스리스), 비연결성
• HTTP 메시지를 통해 통신.
• 단순하고 확장 가능.

1. 클라이언트 서버 구조

• Request Response 구조
• 클라이언트 : 서버에 요청을 보내고, 응답을 대기.
• 서버 : 요청에 대한 결과를 만들어서 응답.
• 이렇게 클라이언트 서버 구조를 만들게 되면 양쪽이 독립적으로 진행 할 수 있음.

2. 무상태 프로토콜 (Stateless)

• 서버가 클라이언트의 상태를 보존하지 않는다.
• Stateful, Stateless 차이
• Stateful : 상태 유지. (서버가 클라이언트의 이전 상태를 보존)
• Stateless : 무상태, 상태를 유지하지 않는다.

Stateful (상태유지)
- 항상같은 서버가 유지되어야 한다.(서버 증설 어려움)
- 중간에 장애 발생 시 처음부터 클라이언트는 처음부터 다시 해야함.

Stateless (무상태)
- 아무 서버나 호출해도 됨. (클라이언트가 요청할때부터 필요 데이터를 모두 담아서 보냄)
- 상태를 보관하지 않고, 필요한 응답만 함.
- 스케일 아웃 (수평 확장 유리) : 같은 기능을 하는 서버군 증설 가능
(무상태는 응답 서버를 쉽게바꿀 수 있다. (무한한 서버 증설 가능))

• Stateless (무상태) 의 한계

모든 것을무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
- 무상태 : 로그인이 필요 없는 단순한 서비스 소개 화면 등.
- 상태유지 : 로그인 등.

로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지.

일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태를 유지.

상태 유지는 최소한만 사용.

3. 비 연결성 (connectionless)

• 연결을 유지하는 모델 (연결 유지 시 서버의 자원 소모)
• 연결을 유지하지 않는 모델 (클라이언트와 서버가 요청을 주고받을 때만 연결하여 최소한의 자원 유지)
• HTTP는 기본적으로 연결을 유지하지 않는 모델.
• 일반적으로 초 단위 이하의 빠른 속도로 응답.
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시 처리하는 요청은 매우 작음.
• 장점 : 서버 자원을 매우 효율적으로 사용할 수 있음.
• 단점은 아래와 같음.

1. TCP/IP 연결을 새로 맺어야 함 : 3 way handshake 시간 추가.

2. 웹 브라우저로 사이트 요청 시 HTML 뿐만 아니라, 자바스크립트, CSS, 추가 이미지 등
수 많은 자원을 함께 다운로드.

• 단점을 해결하기 위해 HTTP는 기본적으로 지속 연결 (Persistent Connections) 로 문제 해결. (HTTP2, 3에서는 더욱 최적화 됨)
• 최대한 스테이스리스하게 설계해야 대용량 트래픽에 대응 가능하다!

4. HTTP 메시지

• HTTP 메시지 구조는 아래와 같다.

시작라인 : 요청 메시지

start-line = request-line / status-line

request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

• HTTP 메서드 (GET:조회)

요청 메시지 - HTTP 메서드
- 종류 : GET, POST, DELETE .. 
- 서버가 수행해야 할 동작을 지정.
- GET : 리소스 조회
- POST : 요청 내역 처리

• 요청 대상(/search?q=hello&hl=ko)

요청 메시지 - 요청 대상
- absolute-path[?query] (절대경로[?쿼리])
- 절대경로="/"로 시작하는 경로

• HTTP Version

시작 라인 : 응답 메시지

start-line = request-line / status-line

status-line = HTTP-version SP status-code SP reason-phrase CRLF

• HTTP 버전
• HTTP 상태 코드 : 요청 성공, 실패를 나타냄

200 : 성공

400 : 클라이언트 요청 오류

500 : 서버 내부 오류

• 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글.

HTTP 헤더

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)

field-name 은 대소문자 구문 없음.

• 용도 : HTTP 전송에 필요한 모든 부가정보.

메시지 바디의 내용, 메시지 바디 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보,
서버애플리케이션 정보, 캐시 관리 정보 등.

• 표준 헤더가 너무 많음.
• 필요 시 임의의 헤더 추가 가능.

HTTP 메시지 바디

• 실제 전송할 데이터.
• HTML 문서, 이미지, 영상, JSON 등 byte 로 표현할 수 있는 모든 데이터 전송 가능.

5. 단순함 확장 가능

• HTTP는 단순하다. (스펙 참고)
• HTTP 메시지도 매우 단순
• 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술.

# URI와 웹 브라우저 요청 흐름

## URI (Uniform Resource Identifier)

• Uniform : 리소스를 식별하는 통일된 방식
• Resource : 자원, URI로 식별할 수 있는 모든 것 (제한 없음)
• Identifier : 다른 항목과 구분하는데 필요한 정보
• URI 는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수있다.
• URI 는 URL, URN을 포함.
• https://www.ietf.org/rfc/rfc3986.txt 

### URL, URN

• URL (Uniform Resource Locator)
• URN (Uniform Resource Name)
• URL - Locator : 리소스가 있는 위치를 지정.
• URN - Name : 리소스에이름을 부여.
• 위치는 변할 수 있지만, 이름은 변하지 않는다.
• urn:isbn:896012345 (어떤 책의 isbn URN)
• URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음.

### URL 분석

scheme://[userinfo@]host[:post][/path][?query][#fragment]


=> 예시.
https://www.google.com:443/search?q=hello&hI=ko

프로토콜 : https
호스트명 : www.google.com
포트 번호 : 443
패스 : /search
쿼리 파라미터 : q=hello&hI=ko

1. scheme

• 주로 프로토콜에 사용.
• 프로토콜 : 어떤 방식으로 자원에 접근할 것인가에 대한 약속 규칙. (예) http, https, ftp 등)
• http 는 80포트 / https 는 443 포트를 주로 사용. (포트 생략 가능)
• https : http 에 보안 추가 (HTTP Secure)

2. userinfo

• URL 에 사용자 정보를 포함해서 인증해야 할 때 사용. (거의 사용하지 않음)

3. host

• 포트(PORT)
• 접속포트
• 일반적으로는 생략 (생략시 http 는 80 / https 는 443)

4. path

• 리소스 경로(path), 계층적 구조

path 예)

/home//file1.jpg

/members

5. query

• key=value 형태
• ? 로 시작, & 로 추가 가능 : ?keyA=valueA&keyB=valueB
• query parameter 또는 query string 등으로 불린다. (웹서버에 제공하는 파라미터 문자 형태)

6. fragment

• html 내부 북마크 등에 사용
• 서버에 전송하는 정보가 아니다.
• 잘 사용하지 않는다.

## 웹 브라우저 요청 흐름

• https://www.google.com:443/search?q=hello&hl=ko 라는 호출이 들어올떄.

1. DNS 조회 : 위 주소를 예로 www.google.com:443 을 바탕으로 DNS 조회
2. HTTP 요청 메시지 생성 : 웹 브라우저가 HTTP 메시지 생성.
3. HTTP 요청 메시지 전송 : SOCKET 라이브러리를 통해 전달.
4. TCP/IP 패킷 생성 (HTTP 메시지 포함) 하여 전달.
5. 응답 패킷 전달