HTTP(Hyper Text Transfer Protocol)
- Request, Response 구조이다
- Client + Server 구조로 생각할 수도 있고, 현재 Meta인 (React + springboot) 같은 구조에 적합하다.
- 서버가 클라이언트의 상태를 모르는 Stateless 구조이다.
- 서버를 물고 있지 않기 때문에 scale in-out 에 유리하다.
- 로그인 후에 작업들에 대해서 상태 유지에 불리하다.
- 구조
HTTP Method --> 행위를 지정
- GET: 데이터의 조회
- POST: 데이터 등록, 프로세스 처리
- PUT: 데이터의 덮어쓰기
- DELETE: 데이터의 삭제
- PATCH: 데이터의 일부분 수정
REST API 설계시 URI 고민
- 회원 관리 시스템 API URI 설계를 고민해보겠습니다.
- 회원 목록: https://naver.com/members --> GET
- 회원 등록: https://naver.com/members --> POST
- 회원 조회: https://naver.com/members/{$id} --> GET
- 회원 수정: https://naver.com/members/{$id} --> PATCH, PUT, POST
- 회원 삭제: https://naver.com/members/{$id} --> DELETE
- 파일 시스템 API URI 설계를 한번 고민해보겠습니다.
- 파일 목록: https://s3.com/files --> GET
- 파일 등록: https://s3.com/files/{$name} --> PUT
- PUT 은 덮어쓰기라는 인식이 있기 때문에 파일이 존재할 경우 등록을 하지 않는다면 POST 로 처리하는 것도 이상적이라 생각한다.
- 파일 조회: https://s3.com/files/{$name} --> GET
- 파일 삭제: https://s3.com/files/{$name} --> DELETE
- 파일 대량 등록 : https://s3.com/files --> POST
HTTP 상태코드
- Client -> Server 로 request 후 response 값에 포함되어 오는 상태값
- 1xx번대: 요청이 수신되어 처리중
- 2xx번대: 요청 정상 처리
- 3xx번대: 요청을 완료하려면 추가 행동이 필요(Redirection)
- 4xx번대: 클라이언트 오류, 서버가 요청을 수행할 수 없음
- 5xx번대: 서버 오류, 서버가 정상 요청을 처리하지 못함
HTTP Header
표현 헤더
- Content-Type : (application/json;) (text/html; charset=UTF-8;)
- Content-Encoding: gzip; (압축시 사용)
- Content-Language: ko;
- Content-Length: 1024;
-
협상 헤더
클라이언트가 희망하는 요청 타입
- Accept : image/*; text/html; text/*;
- Accept-Charset : 클라이언트가 희망하는 charset(UTF-8;)
- Accept-Encoding : 서버에 희망하는 압축방식
- Accept-Language : 1~0 (1에 가까울수록 우선순위가 높다)
전송 방식
- 단순 전송: Content-Type: 1024;
- 압축 전송: Content-Type: 1024; Content-Encoding: gzip;
- 분할 전송: Transfer-Encoding: chunked; (body 부분에서 생성되는 대로 전달해 주겠다.)
- 범위 전송: Content-Range: bytes 0~1024 / 2048;
일반 정보
- referer: 이전 사이트 주소
- user-agent: 웹브라우저, IOS, Android
특별한 정보
- Host: 처음 요청한 domain 주소(bithumb.com)
- Location: HTTP 상태코드에 따른 서버쪽에서 요청희망하는 도메인 주소
- Retry-After: 몇분후에 서비스를 다시 이용가능한지(사용잘안함)
인증(Authorization)
- Authorization: Basic XXXXXXXXXXXXXXXXXXXXX
- 인증 방식에 따라 value 값은 다름
- 401 에러시 WWW-Authenticate: xxxxx(필요한정보) 를 제공할수도 있다.
쿠키
- 서버는 클라이언트 요청시 set-cookie 를 할수 있고, 웹브라우저가 set-cookie 를 실행
- 다음요청부터 브라우저에서 알아서 cookie 를 전송해줌.
- 서버에 전송하고 싶지 않다면 localStorage, sessionStorage 를 쓰면 좋다.
- 도메인을 설정하면 contains 처럼 작동, 미설정시 equals 로 작동
- Path 설정이 가능 하고 package 형식으로 하위는 다 전송이 가능하다.
- secure 쿠키는 https만 전송
- httpOnly 쿠키는 JS에서 접근불가(XSS방어)
- sameSite 쿠키는 도메인이 같은 경우만 쿠키 전송(CSRF방어)
캐시
브라우저 캐시
- Cache-Control:
- no-cache: 데이터는 캐쉬해서 되지만, server에서 항상 검증하고 사용해
- no-store: 데이터에 민감한 정보가 있어서 캐쉬해서 사용하면 안돼
- max-age=60: 60초 동안만 캐시해서 사용해
- expired=mon, 10, 2021: max-age가 우선시 된다.
- Last-Modified(server)/If-Modeified-Since(client): 20220101000000 검증헤더와 조건부요청을 통해 304 Not Modified 를 통해 해더요청으로만 자원을 효율적으로 줄일수 있다.
- ETag(Server)/If-None-Match: "v1" 을 통해 버전(태그) 방식으로도 할수 있다.
프록시 캐시
- CDN 서비스라고 하고, 미국에 origin서버가 존재할때, 한국에 캐시서버를 두고 한국서버로 요청하는 것을 말한다.
캐쉬 무효화
- 캐시를 절대 하면 안되는 응답
- Cache-Control: no-cache, no-store, must-revalidate(순단시 504에러 처리)
- Pragma: no-cache(http 1.0 하위호환)
