ex. 메시지 바디의 내용/크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등
필요시 임의 헤더 추가 가능
(3) 메시지 바디
용도
실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능
🗒️ 예시
(2) status-line
HTTP 상태 코드
요청 성공, 실패 나타냄
200 : 성공
400 : 클라이언트 요청 오류
500 : 서버 내부 오류
이유 문구
사람이 이해할 수 있는 짧은 상태 코드 설명 글
📕 4. HTTP 메서드
1) HTTP API를 만들어보자
요구사항 ➡ API URI 설계 (리소스 식별)
URI는 리소스만 식별, 리소스와 해당 리소스를 대상으로 하는 행위를 분리
리소스 : 회원
행위 : 조회, 등록, 삭제, 변경
리소스는 명사, 행위는 동사
행위(메서드)는 어떻게 구분
🗒️ 예시 : 회원 정보 관리 API 생성
(1) 요구사항 정리
회원 목록 조회
회원 조회
회원 등록
회원 수정
회원 삭제
(2) API URI 설계 (Uniform Resource Identifier)
회원목록 조회 / read-member-list (X)
회원조회 / read-member-by-id (X)
회원등록 / create-member (X)
회원수정 / update-member (X)
회원삭제 / delete-member (X) ➡ 리소스 : 회원 / members / {id}
📖 참고 📖 리소스
리소스 식별 : 리소스를 URI에 매핑
ex. 회원 등록/수정/조회하는 것이 리소스가 아니고, 회원 개념이 리소스
2) HTTP 메서드
종류
(1) GET : 리소스 조회
(2) POST : 요청 데이터 처리 (주로 등록에 사용)
(3) PUT : 리소스 대체 (해당 리소스 없을 경우 생성)
(4) PATCH : 리소스 부분 변경
(5) DELETE : 리소스 삭제
(6) HEAD : GET 동일하지만, 메시지 부분 제외하고 상태 줄 + 헤더만 반환
(7) OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드) 설명 (주로 CORS에서 사용)
(8) CONNECT : 대상 자원으로 식별되는 서버에 대한 터널 설정
(9) TRACE : 대상 리로스에 대한 경로를 따라 메시지 루프백 테스트 수행
(1) GET
개념
리소스 조회
서버에 전달하려는 데이터를query(쿼리 파라미터/스트링)통해 전달
GET으로 메시지 바디 전달 가능 (지원하는 곳 많지 않아 권장X)
🗒️ 예시
서버에 메시지 전달
서버가 응답 데이터 생성 후 전송
(2) POST
개념
요청 데이터 처리
전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
메시지 바디를 통해 서버로 요청 데이터 전달 ➡️ 서버는 요청 데이터 처리
리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 정해야함
기능
새 리소스 생성 (등록) ➡️ 서버가 아직 식별하지 않은 새 리소스 생성 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 기사 그룹에 메시지 게시 ➡️ 기존 자원에 데이터 추가
요청 데이터 처리 ➡️ HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공 ➡️ 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 기사 그룹에 메시지 게시 ➡️ POST 결과로 새로운 리소스 생성되지 않을 수도 있음 (ex. POST /orders/{orderId}/start-delivery (컨트롤 URI)
다른 메서드로 처리하기 애매한 경우 (JSON으로 조회 데이터 넘겨야 하는데, GET 메서드를 사용 어려운 경우)
🗒️ 예시
서버로 메시지 전달
서버가 신규 리소스 생성
서버 응답 데이터 전송 (Location: 자원이 신규 생성된 경로)
(3) PUT
개념
리소스 완전 대체 (없으면 생성)
POST와 차이점 : 클라이언트가 리소스를 식별함 (리소스 위치 알고 URI 지정)
🗒️ 예시
리소스가 있는 경우
리소스 없는 경우
(4) PATCH
개념
리소스 수정
🗒️ 예시
일부 필드 수정 가능
(5) DELETE
개념
리소스 제거
🗒️ 예시
3) HTTP 메서드의 속성
안전 (Safe Methods)
호출해도 리소스 변경X
멱등 (Idempotent Methods)
여러번 호출해도 결과 동일함 (f(f(x))=f(x))
멱등 메서드 : GET, PUT, DELETE (POST X)
활용 : 자동 복구 메커니즘 (서버가 정상 응답 아닐경우 클라이언트가 같은 요청 다시 해도 되는지 판단)
캐시가능 (Cacheable Methods)
응답 결과 리소스를 캐시해서 사용 가능한지
캐시가능 메서드 : GET, HEAD, POST, PATCH (POST, PATCH 본문 내용까지 캐시 키로 고려해야 해서 구현 쉽지X)
📕 5. HTTP 메서드 활용
1) 클라이언트에서 서버로 데이터 전송
방식
쿼리 파라미터를 통한 데이터 전송 : GET (🗒️ 예시 : 정렬 필터 (검색어))
메시지 바디를 통한 데이터 전송 : POST, PUT, PATCH (🗒️ 예시 : 회원 가입, 상품 주문, 리소스 등록, 리소스 변경)
(1) 정적 데이터 조회
쿼리 파라미터 미사용 (리소스 경로로 단순 조회 가능)
조회는 GET 사용
🗒️ 예시 : 이미지, 정적 텍스트 문서
(2) 동적 데이터 조회
쿼리 파라미터 사용
조회 조건 줄여주는 필터 (조회 결과 정렬 조건에 사용)
조회는 GET 사용
🗒️ 예시 : 검색, 게시판 목록에서 정렬 필터(검색어)
(3) HTML Form을 통한 데이터 전송
HTML Form 제출시 GET/POST 전송
application/x-www-form-urlencode 사용 ➡️ form의 내용을 key-value 형식으로 만들고, HTTP 메시지 바디에 넣어 전송 (한글, 숫자 등 url encoding)
multipart/form-data 사용 ➡️ 파일 업로드 등 바이너리 데이터 전송시 사용 ➡️ 다른 종류의 여러 파일과 form 내용 함께 전송 가능
🗒️ 예시 : 회원 가입, 상품 주문, 데이터 변경
파일 전송
(4) HTML API를 통한 데이터 전송
POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송
GET : 조회, 쿼리 파라미터로 데이터 전달
application/json 사용 (TEXT, XML, JSON 등)
서버 to 서버 (백엔드 시스템 통신)
앱 클라이언트 (아이폰, 안드로이드)
웹 클라이언트 (HTML에서 Form 전송 대신 JS 통한 통신(React, Vuejs)에 사용 (AJAX))
🗒️ 예시 : 회원 가입, 상품 주문, 데이터 변경
2) HTTP API 설계 예시
(1) HTTP API - 컬렉션
POST 기반 등록
서버가 리소스 URI 결정
🗒️ 예시 : 회원 관리 API 제공
🗒️ 예시 : 회원 관리 시스템 만들기
1️⃣ :API 설계- PUT 기반 등록
회원 목록 /members ➡️GET
회원 등록 /members ➡️POST
회원 조회 /members/{id} ➡️GET
회원 수정 /members/{id} ➡️PATCH, PUT, POST
회원 삭제 /members/{id} ➡️DELETE
2️⃣POST- 신규 자원 등록 특징
클라이언트는 등록될 리소스의 URI를 모름
회원등록 /members ➡️POST
POST /members
서버가 새로 등록된 리소스 URI 생성
HTTP/1.1 201 Created
Lacation:/members/100
컬렉션(Collection)
서버가 관리하는 리소스 디렉토리
서버가 리소스의 URI를 생성하고 관리
컬렉션 /members으로 구분
(2) HTTP API - 스토어
PUT 기반 등록
클라이언트가 리소스 URI 결정
🗒️ 예시 : 정적 컨텐츠 관리, 원격 파일 관리
🗒️ 예시 : 파일 관리 시스템
1️⃣ :API 설계- PUT 기반 등록
파일 목록 /files ➡️GET
파일 조회 /files/{filename} ➡️GET
파일 등록 /files/{filename} ➡️PUT
파일 삭제 /files/{filename} ➡️DELETE
파일 대량 등록 /files ➡️POST
2️⃣ :PUT- 신규 자원 등록 특징
클라이언트가 리소스 URI 알고 있어야함
파일등록 /file/{filename} ➡️PUT
PUT /files/star.jpg
클라이언트가 직접 리소스의 URI 지정
스토어(Store)
클라이언트가 관리하는 리소스 저장소
클라이언트가 리소스의 URI를 알고 관리
스토어 /files로 구분
(3) HTML FORM - 컨트롤 URI
GET, POST만 지원
AJAX 등 기술 사용해서 해결 가능
순수 HTML + HTML FORM 사용
컨트롤 URI
GET, POST 지원의 제약 해결하기 위해 동사로 된 리소스 경로 사용
HTTP 메서드로 헤결하기 애매한 경우 사용 (HTTP API 포함)
POST의 컨트롤 URI : /new, /edit, /delete
🗒️ 예시 : HTML FORM 사용
1️⃣ :API 설계
회원 목록 /members ➡️GET
회원 등록 폼 /members/new ➡️GET
회원 등록 /members, /members/new ➡️POST
회원 조회 /members/{id} ➡️GET
회원 수정 폼 /members/{id}/edit ➡️GET
회원 수정 /members/{id}, /members/{id}/edit ➡️POST
회원 삭제 /members/{id} ➡️POST
2️⃣POST- 신규 자원 등록 특징
(4) URI 설계 개념
문서(document)
단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
🗒️ 예시 : /members/100, /files/star.jpg
컬렉션 (Collection)
서버가 관리하는 리소스 디렉터리
서버가 리소스의 URI를 알고 관리
🗒️ 예시 : /members
스토어 (Store)
클라이언트가 관리하는 자원 저장소
클라이언트가 리소스의 URI를 알고 관리
🗒️ 예시 : /files
컨트롤러 (Controller), 컨트롤 URI
문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
동사를 직접 사용
🗒️ 예시 : /members/{id}/delete
📕 6. HTTP 상태코드
1) HTTP 상태코드 소개
(1) 상태코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
1xx (Informational) : 요청이 수신되어 처리중 (사용X)
2xx (Successful) : 요청 정상 처리
3xx (Redirection) : 요청을 완료하려면 추가 행동 필요
4xx (Client Error) : 클라이언트 오류, 잘못된 문법 등 서버가 요청을 수행할 수 없음
5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함
(2) 모르는 상태코드의 경우
클라이언트가 인식할 수 없는 상태코드를 서버가 반환할 경우 ➡️ 상위 코드로 해석해서 처리 (299 ???이면 2xx(Successful)
미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨
2) 2xx - 성공
클라이언트의 요청을 성공적으로 처리
(1) 200 OK
요청 성공
(2) 201 Created
요청 성공해서 새로운 리소스가 생성됨
생성된 리소스는 응답의Location 헤더 필드로 식별
(3) 202 Accepted
요청이 접수되었으나 처리가 완료되지 않았음
배치 처리 같은 곳에서 사용
🗒️ 예시 : 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함
(4) 204 No Content
서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
🗒️ 예시 : 웹 문서 편집기에서 save 버튼
save 버튼의 결과로 아무 내용이 없어도 됨
save 버튼을 눌러도 같은 화면을 유지해야함
결과 내용이 없어도 204 메시지(2xx)만으로 성공 인식 가능
3) 3xx - 리다이렉션
요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
📖 참고 📖 리다이렉션
redirect 개념
웹 브라우저는 3xx 응답의 결과에Location 헤더가 있으면, Location 위치로 자동 이동
자동 리다이렉트 흐름
redirection 종류
영구 리다이렉션
특정 리소스의 URI가 영구적으로 이동 (경로 변경 알림 용도)
원래 URL 사용X, 검색 엔진 등에서도 변경 인지
301 Moved Permanently, 308 Permanent Redirect
🗒️ 예시 : /event (기존) ➡️ /new-event (변경)
일시 리다이렉션
리소스 URI가 일시적으로 변경
검색 엔진 등에서 URL 변경하면 X
302 Found, 303 See Otehr, 307 Temporary Redirect
🗒️ 예시 : 주문 완료 후 주문 내역 화면으로 이동
PRG: Post/Redirect/Get
PRG 이후 리다이렉트 하면 URL이 이미 POST ➡️ GET으로 리다이렉트됨
새로고침 해도 GET으로 결과 화면만 조회
🗒️ 예시 : PRG 사용하지 않으면 웹브라우저 새로고침시 POST 재요청
POST로 주문 후에 새로고침으로 인한 중복 주문 방지
POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
새로고침해도 결과 화면을 GET으로 조회
중복 주문 대신에 결과 화면만 GET으로 다시 요청
특수 리다이렉션 (결과 대신 캐시 사용)
(2) 300 Mutlple Choices
사용X
(3) 301 Moved Permanently
영구 리다이렉션
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
(4) 302 Found
일시 리다이렉션
HTTP 메서드 유지하기 위해 등장했지만, 웹 브라우저들이 GET으로 바꿔버림 ➡️ 명확한 303/307 등장
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 (GET으로 변할 수 있음)
