클라이언트에서 서버로 데이터 전송
- 방식
- 쿼리 파라미터 : GET
- 메시지 바디 : POST, PUT, PATCH
[상황]
-
정적 데이터 조회(GET)
- 이미지, 정적 텍스트 문서
- 쿼리파라미터X 리소스경로O
-
동적 데이터 조회(GET)
- 쿼리 파라미터 사용, ?q=hello&hl=ko
- 검색, 게시판 목록 정렬 필터
-
HTML Form 태그를 통한 데이터 전송
- GET, POST만 지원
- Content-Type
1. application/x-www-form-urlencoded 사용
: 쿼리 파라미터 형식(key=value)형식으로 전송
: 전송 데이터를 url encoding 처리, 예) abc김 -> abc%EA%E9%80
2. multipart/form-data
: 바이너리 데이터 전송 시 사용
-
HTTP API를 통한 데이터 전송
- 서버 to 서버(백엔드 시스템 통신), 앱 클라이언트, AJAX(JS를 통한 통신)
- Content-Type : application/json
HTTP API 설계 예시
- POST 기반 등록(대부분) - 컬렉션
- 회원 관리 시스템
- 특징
- 클라이언트는 등록될 리소스의 URI를 모른다
- 서버가 새로 등록된 리소스 URI를 생성해준다
- 컬렉션 : 서버가 관리하는 리소스 디렉토리
- PUT 기반 등록 - 스토어
- 파일 관리 시스템
- 특징
- 클라이언트가 리소스 URI를 알고 있어야 한다
- 클라이언트가 직접 리소스의 URI를 지정한다.
- 스토어 : 클라이언트가 관리하는 리소스 저장소
- HTML FORM 사용
- GET, POST만 지원 -> 제약
- 컨트롤 URI 사용 ~예) /new, /edit, /delete 등
[참고하면 좋은 URI 설계 개념]
- document
- 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
- 예) /members/100, /files/star.jpg
- collection
- 서버가 관리하는 리소스 디렉토리
- 서버가 리소스의 URI를 생성하고 관리
- 예) /members
- store
- 클라이언트가 관리하는 자원 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- 예) /files
- controller, control URI
- 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
- 동사를 직접 사용
- 예) /members/{id}/delete
HTTP 상태 코드
1xx : 요청이 수신되어 처리 중, 거의 사용X
2xx : 요청 정상 처리
200 OK / 201 Created / 202 Accepted(요청접수O, 처리완료X) / 204 No Content(요청O, 응답 데이터X, 예: 웹 문서 편집기의 save 버튼)
3xx : 요청을 완려하려면 추가 행동이 필요(Redirection)
Redirection : 응답 결과에 location이 있으면, location 위치로 자동 이동
- 영구 다이렉션(301, 308) : 리소스의 URI가 영구적으로 이동
- 301 Moved Permanently : 메서드가 GET으로 변경, 본문 제거(MAY) ~> 실무에서 많이 사용
- 308 Pemanent Redirect : 메서드&본문 유지
- 일시적 리다이렉션(302, 307, 303) : 일시적 변경
- 302 Found : 메서드가 GET으로 변경, 본문 제거(MAY) ~> 실무에서 많이 사용
- 307 Temporary Redirect : 메서드&본문 유지
- 303 See Other : 메서드가 GET으로 변경
- 예시 : PRG(Post/Redirect/Get)
POST로 주문 후에 새로 고침으로 인한 중복 주문 방지
POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
PRG 이후 리다이렉트 ~> 새로 고침 해도 GET으로 결과 화면만 조회
- 기타 리다이렉션
- 300 Multiple Choices : 안쓴다
- 304 Not Modified : 캐시로 리다이렉트, 클라이언트는 로컬PC에 저장된 캐시를 재사용
4xx : 클라이언트 오류, 잘못된 문법 등
401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증 필요, 로그인 안됨
403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함, 접근 권한 불충분, 접근 불가 어드민에 접근
404 Not Found : 요청 리소스가 서버에 없음
5xx : 서버 오류, 서버 정상 요청처리 X
500 Internal Server Error : 애매하면 500 오류
503 Service Unavailable : 서비스 이용 불가
=> 웬만하면 5xx 에러를 만들면 안됨
HTTP 헤더
- 용도 : HTTP 전송에 필요한 모든 부가정보
- 분류 : General 헤더, Request 헤더, Response 헤더, Entity 헤더(-> Representation 헤더)
- 메시지 본문을 통해 표현 데이터 전달
-
표현 : 요청이나 응답에서 전달할 실제 데이터
표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공(데이터 유형, 길이, 압축정보 등)
• Content-Type: 표현 데이터의 형식
• Content-Encoding: 표현 데이터의 압축 방식
• Content-Language: 표현 데이터의 자연 언어
• Content-Length: 표현 데이터의 길이 -
협상(콘텐트 네고시에이션) : 클라이언트가 선호하는 표현 요청
• Accept : 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accpet-Language : 클라이언트가 선호하는 자연 언어 -
Quality Value(q) : 협상과 우선순위
• 0~1, 클수록 높은 우선순위
• 구체적인 것이 우선한다
• 구체적인 것을 기준으로 미디어 타입을 맞춘다
[전송방식]
• 단순전송 : Content-Length를 알고 있을 때
• 압축전송 : Content-Encoding
• 분할전송 : Transfer-Encoding:chunked
• 범위전송 : Content-Range
[일반 정보]
• From : 유저 에이전트의 이메일 정보, 잘 사용X
• Referer : 이전 웹 페이지 주소
• User-Agent : 유저 에이전트 애플리케이션 정보, 통계 정보
• Server : 요청을 처리하는 origin 서버(찐막 서버)의 소프트웨어 정보
• Date : 메시지가 생성된 날짜
[특별한 정보]
• Host : 요청한 호스트 정보(도메인), 필수
• Location : 3xx 오류의 페이지 리다이렉션
• Allow : 허용 가능한 HTTP 메서드, 405의 응답에 포함해야함
• Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
[인증]
• Authorization : 클라이언트 인증 정보를 서버에 전달
• WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의
쿠키
- HTTP는 stateless이므로 서로 상태를 유지하지 않음
- Set-Cookie : user=홍길동 -> 쿠키 저장소에 user=홍길동 저장 -> Cookie : user=홍길동
- 쿠키 정보는 항상 서버에 전송됨 -> 네트워크 트래픽 추가 유발
- 최소한의 정보만 사용(세션 id, 인증 토큰)
- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지를 참고
- 보안에 민감한 데이터는 저장하면 안됨
[쿠키 생명주기]
expires= : 만료일이 되면 쿠키 삭제, max-age=3600(3600초)
세션쿠키 : 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
영속쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지
[쿠키 도메인]
도메인 명시 : 명세힌 문서 기준 도메인 + 서브 도메인에 모두 접근
도메인 생략 : 서브 도메인에서 접근 불가
[쿠키 경로]
path=/ 루트로 지정
[쿠키 보안]
Secure : https만 전송
HttpOnly : JS에서 접근 불가
SameSite : 요청도메인==설정도메인 에만 전송
캐시
- 메모리까지 가지 않고 캐시에서 조회 -> 성능향상
- 캐시 시간 초과
- 검증 헤더 : Last-Modified: (데이터 최종 수정일)
- 데이터 수정 X : 304 Not Modified ... HTTP Body 없음
- 조건부 요청 : if-modified-since :
=> 캐시 수정 여부는 "검증 헤더 + 조건부 요청"을 통해 알 수 있다.
[검증 헤더]
• 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
• Last-Modified , ETag
[조건부 요청 헤더]
• 검증 헤더로 조건에 따른 분기
• If-Modified-Since: Last-Modified 사용
• If-None-Match: ETag 사용
• 조건이 만족하면 200 OK
• 조건이 만족하지 않으면 304 Not Modified
- ETag(Entity Tag) : 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠. 데이터가 변경되면 이름을 바꾸어서 변경함(Hash를 다시 생성)
ETag만 서버에 보내서 같으면 유지, 다르면 받기!
캐시 제어 로직을 서버에서 완전히 관리
[프록시 캐시 서버]
가짜 캐시 서버를 구축 -> 성능향상
[캐시 무효화]
Cache-Control: no-cache, no-store, must-revalidate
Cache-Control: no-cache : 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
Cache-Control: no-store : 데이터에 민감한 정보가 있으므로 저장X
Cache-Control: must-revalidate : 캐시 만료후 최초 조회시 원 서버에 검증해야 함
