HTTP

1. 인터넷 통신

1) 컴퓨터1 -  인터넷 - 컴퓨터2

• 1에서 2로 데이터를 보내면 인터넷 망에서 무수히 많은 노드들을 거치게 된다.**

2) IP(프로토콜)

• IP주소로 전달하는데 패킷이라는 단위로 전송
• IP 패킷
  • 정보
    • 출발지 IP
    • 도착지 IP
  • 특징 혹은 문제점
    • 패킷의 데이터 크기가 크면 나누어서 보낸다.
    • 중간 노드를 거치면서 패킷이 소실될 가능성 존재.
    • 중간 노드를 거치면서 패킷의 순서가 바뀔 가능성 존재

3) TCP

• 패킷이 가진 한계점을 해결해줌.
• TCP/IP 패킷
  • 정보
    • IP패킷 정보 안에 포함된다.
    • 출발지 PORT
    • 도착지 PORT
    • 전송 제어
    • 순서
    • 검증 정보
    • 전송 데이터

4) UDP

• HTTP3와 함께 쓰임.
• TCP가 하는 작업들을 개발자가 직접 컨트롤해 속도를 더 빠르게 향상할 수 있음.

2. HTTP

1) HTTP 메서드

(1) GET

• http 스펙상 GET도 메시지 바디를 써서 데이터를 보낼 수 있다.
• 하지만 지원하지 않는 서버도 많고, 그렇기 때문에 실무에서는 권장하지 않는 방식이다.
• form으로 데이터를 보내면 http 바디가 아니라 쿼리 파라미터에 들어간다.

(2) POST

• FORM
  • form으로 데이터를 보내면 http 메시지를 생성을 해준다.
  • key=value 스타일로 데이터를 만들고 http 바디에 넣는다.
  • encrype=“multipart/form-data”
    • 여러 데이터를 전송할 때 사용.
    • 주로 바이너리 데이터 전송에 사용(사진, 엑셀 파일 등)
    • 파일 업로드를 한다면 form-data를 해야 한다는 것을 기억해야 함**

2) HTTP 메서드 설계

(1) API 설계

• POST 기반 Collection
  • 실무에서는 이 컬렉션을 대부분 사용한다.*
  • POST는 모델 생성 시 id값(PK)을 서버에서 직접 만듦.
• PUT 기반 store
  • 실무에서는 이 스토어를 거의 사용하지 않는다.*
  • PUT은 모델 생성 시 id값을 클라이언트에서 보내준 값을 가지고 작업만 해줌.
• 수정
  • PATCH 가 제일 좋다
  • PUT은 완전히 덮을 수 있을 때 사용해야 한다.
  • 둘 다 사용하기 애매할 때 POST를 사용.

(2) HTML FORM 사용

• get, post 만 사용 가능
• delete?
  • /members/{id}/delete (컨트롤 URL)
    • method: POST로 보내야 한다.
  • /members/{id} : method: DELETE로 보내는 게 가장 좋지만 form 사용 시 방법이 POST밖에 없기 때문이다.

(3) 컨트롤 URI

• 최대한 resource와 HTTP 메서드를 활용해서 작업을 하고,
• HTTP 메서드를 사용하기 애매할 때 컨트롤 URI(new, edit, delete etc)를 사용해야 한다.**
• 그리고 이름은 동사를 사용해야 한다. resource에 대한 행위 이므로,

(4) URL 설계 팁

• 먼저 resource만 가지고 설계 (복수 이름 사용)
• 만약 이것 가지고 해결이 안 되는 상황이 있다면,
• 그때 컨트롤러 URL로 해결할 것*

3) HTTP 상태 코드

• 상태 코드는 너무 많으므로 보통 범위를 정해서 사용하는 것이 좋다.
• 실무에서는 2xx 경우 200만 사용하는 경우도 많고, 201까지도 가끔 사용한다.
• status 코드를 서버에서 직접 지정해서 사용할 수 있다.

(1) 2xx

(2) 3xx

• 301~308까지가 중요
• 자동 리다이렉트
  • 예전 /event 경로를 주면 이 경로가 아닌 새로운 경로 /new_event 로 바꿔서 서버에 다시 요청 후 결과값(200)을 받는다.
• 301, 308 은 거의 사용하지 않음.
• Temporary Redirect 302,307,303- 213p
  • 302,307,303 기능은 다 동일. 특징만 약간 다름
  • 이 temporary redirect를 많이 사용
  • 307,303을 많이 사용하길 희망하지만, 실무에서는 아직도 302를 많이 쓰고,
  • 이렇게 해도 별 문제가 되지 않는다.
  • 사용법
    • POST로 주문 요청한다면, 서버에서 302 Found 상태 코드를 넘겨주면, 새로고침 시 POST가 아닌 GET으로 요청이 가서 다시 또 주문하는 것이 아니라 결과 화면만 새로고침이 되는 형태가 된다.
• 304 Not Modified
  • 많이 사용함.

(3) 4xx

• 서버 개발자는 철저하게 validation 체크를 해서 클라이언트가 잘못했다면 4xx 코드번호를 리턴해줘야 한다.*** 서버 쪽 코드번호가 아니라,
• 이렇게 정확하게 잘못된 쪽을 가려야 어디를 확실하게 확인할지 정할 수 있다.
• 4xx 에러는 http 스펙을 잘못 맞추거나 인증이 안된 케이스가 많다.

(4) 5xx

• 500으로 내보내면 된다 거의
• 500 에러는 진짜 서버에 뭔가 문제가 있을 때 내야 한다.*
• null pointer exception, db가 내려가거나 등등 진짜 서버에 문제가 있을 때 500 에러를 내야 한다.
• 나머지 에러들은 400이나 200으로 해결해야 한다.*
• 이러한 에러 종류는 500 에러로 내면 안된다.
  • 고객이 잔액이 부족한 경우
  • 미성년자가 19+를 구매하려고 하는 경우
  • etc

4) HTTP 헤더1

(1) 전송 방식

• 분할 전송
  • Transfer-encoding: chunked
    • chunked는 여러 개로 쪼개서 보낸다는 의미.
    • 이때에는 content-length를 보내면 안 됨 (예상 불가이므로)

5) HTTP 헤더2 - 캐시와 조건부 요청

(1) 브라우저 개발자 도구에 network -> Status에서 상태 코드(ex 200)가 연한 것(약간 회색)은  캐시에서 불러온 것이다.*

(2) Cache-control

• 확실한 캐시 무효화 응답
  • 캐시를 적용을 안 해도 GET 요청의 경우 웹브라우저가 임의로 캐시를 하기도 한다.
  • 그래서 이 페이지는 절대 캐시가 되면 안 된다면 cache-control: no-cache, no-store, 등을 넣어줘야 한다.
  • 그래서 서버 쪽에서 http 응답 코드를 만들 때, no-cache, no-store, must-revalidate까지 넣어줘야 한다.*
  • 이러한 것들은.. 필요하다면 http 응답 코드를 서버에서 이렇게 보내줘야 정확하게 내가 원하는 대로 통신을 할 수 있다.

 

 

마지막으로.. 모든 프레임워크는 http 기반에 맞춰져서 돌아간다.