HTTP 방식으로 요청을 보낼 때 형식
HTTP 1.1 방식으로 GET 요청을 보냄
GET / HTTP/1.1
Host: www.naver.com
Cookie: PM_CK_loc=dac2d79568fae9dbe0d15731e12baeb29d1dadd11864edcc1e7e0be435a207cd이런 형식으로!
웹 브라우저의 흐름
DNS(Domain name system)조회
-> HTTP 요청 메시지 작성
-> Socket 라이브러리를 통해 전달
-> TCP/IP 작성되고 이 안에 HTTP 메시지가 포함
HTTP
HyperText Transfer Protocol
원래는 html 전송용이었으나 현재는 모든 형태(이미지, 음성, 영상, 파일, json, xml..etc)를 전송한다.
HTTP 1.1에서 양식은 고정되었다. HTTP2와 HTTP3은 성능 개선만 된거지 양식은 그대로!
특징
1. 클라이언트 서버 구조
Request를 보냄 -> response를 기다림
클라이언트에 ui, 서버 쪽에 logic
즉, 클라이언트와 서버의 분리!
문제가 생겼을 경우 각각 해결하면 된다.
2. 무상태 프로토콜(stateless)
서버가 클라이언트 상태를 보존하지 못함.
즉, 서버가 우리의 상태를 기억하지 않음!
장점 : 응답 서버를 쉽게 바꿀 수 있음.
예외 : 세션 로그인은 상태가 있음. (최소한으로 사용)
3. 비연결성
기본적으로 연결을 유지하지 않으며,
일반적으로 초 단위의 빠른 응답과 최소한의 자원을 사용한다.
HTTP 메세지의 구조
Request line GET / HTTP/1.1 과
Status line HTTP/1.1 200 OK 정도의 차이가 있다!
HTTP method
- Get : 데이터를 쿼리스트링으로 전달
- Post : 메시지 바디를 통해 서버로 요청 데이터 전달.
DB의 상태 변화가 일어나는? 데이터를 처리함.
프로세스를 처리하거나..
새로운 리소스가 생성되지 않을 수도..
조회 할 양이 너무 많을 때 GET쓰기도 함 - Put or Patch : 수정. Put은 파일 붙여넣기와 동일. 없으면 만들고 있으면 덮어쓴다. Patch는 부분 변경
- Delete
쿼리 파라미터로 전송 :
GET검색 정렬 필터
메시지 바디 :POST,PUT,PATCH회원가입, 상품 주문, 리소스 등록 변경
데이터의 전송 방식
1. Form 방식
기본적으로 get, post만 지원
2. HTTP API 방식
서버 to 서버, 앱 클라이언트, 웹 클라이언트(ajax). Post,put,patch도 가능
HTTP 상태 코드
- Informational responses (100 – 199)
- Successful responses (200 – 299)
- Redirection messages (300 – 399)
- Client error responses (400 – 499)
- Server error responses (500 – 599)
100번대
1xx 요청이 수신되어 처리 중. 거의 사용되지 않음
200번대
2xx 요청 정상 처리
200 OK
201 Created
202 Accepted
204 No Content
보통은 200이랑 201만 사용.
300번대
3xx 추가 행동 필요
주로 redirect를 해줄 때
400번대
4xx 클라이언트 에러
400 요청 내용을 다시 검토.
API 스펙이 맞는지! 보통 폰트의 오타나 누락
401 로그인이 안되어있다. 인증이 안됨
403 권한이 없음.
404는 보통 url이 틀렸을 때!
잘못 된 문법. 오류의 원인이 클라이언트에 있다.
500번대
5xx 서버 에러
500 서버 내부 문제
503 서버가 일시 과부하
잘 보냈는데 서버 쪽에 문제가 생겨서. 백엔드 쪽으로 확인하자!
HTTP Header
- Field name(key) + value
※ Field name 은 대소문자 구분이 없다.
http 전송에 필요한 모든 부가정보.
body의 데이터를 해석할 수 있는 정보를 제공한다.
종류
- 표현 : 리소스에 대한 정보(형식, 인코딩 방식, 언어, 길이..)
- 컨텐트 협상 : 요청 시에만 들어감.
- 일반 정보 : 어디서 왔니 어느 브라우저니 어떤 소프트웨어니...
- 특별 정보 : host 정보, allow(허용 가능한 메소드…)
- 인증 : 인증정보
- 쿠키 : HTTP가 무상태 연결이기 때문에 상태를 매번 보내줘야 함. 브라우저에 사용자 정보를 저장… 서버에서 클라이언트로 쿠키 전달. 쿠키 저장
- 캐시
ㅡㅡ
API를 restful하게 짜자!
가장 중요한 건 리소스 식별.
회원이라는 개념 자체가 리소스고 uri에 이것이 매핑되는 것. 거기에 하는 행위는 메소드
라는데 사실 아직 감이 덜 잡힌다.
리소스와 행위를 분리하는 것이 restful한 API라고 함!
(리소스 : 회원, 행위 : 조회, 등록, 삭제, 변경)
