HTTP - 2022-3-30

비 연결성

• HTTP는 기본이 연결을 유지하지 않는 모델
• 연결을 유지한다면 많은 리소스를 낭비하게 됨
• 서버에서 동시에 처리하는 요청이 실제로도 적은데 연결을 유지하면 비효율적임
• TCP/IP 연결 3way handshake, HTML, CSS, Js, 추가 이미지 등 수 많은 자원이 함께 다운로드됨 → 시간이 많이 들게 됨
• HTTP 지속 연결로 문제 해결
  • 요청 후 다 받은 후에 연결을 종료함
• HTTP/2, HTTP/3에서는 더 최적화가 됨
• 무상태로 설계할 수 있으면 무상태가 좋음

HTTP 메시지

• HTTP 요청 메시지, 응답 메시지는 구조가 조금씩 다름
• 요청 메시지
• HTTP 메서드 → GET, POST, PUT, DELETE...
• 요청 대상 → ?쿼리, 절대경로는 “/”로 시작하는 경로
  • (절대경로[?쿼리]) 의 형태
• HTTP 버전
• 상태 코드 (200: 성공, 400: 클라이언트 요청 오류, 500: 서버 내부 오류)
• HTTP 헤더 → HTTP 전송에 필요한 모든 부가정보
• HTTP 메시지 바디 → 실제 전송할 데이터

HTTP API

• URI 설계에서 가장 중요한 부분은 리소스 식별
• 회원 서비스에서 리소스는 회원이다. 회원 조회, 삭제, 등록 등이 아니다.
• 리소스가 명사라면 행위인 동사는 HTTP 메서드가 맡는다.

HTTP 메서드

• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스 대체, 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제
• HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
• CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
• GET은 쿼리 파라미터, 쿼리 스트링을 통해서 전달
• POST는 메시지 바디를 통해 서버로 요청 데이터 전달
  • 리소스만으로 설계하기 어려운 경우 컨트롤 URI로 설계해야 함
• POST는 모든 것이 가능하므로 애매하면 POST를 사용
  • 하지만 맞는 메서드가 있으면 그것을 사용해야 함
• PUT은 리소스가 있으면 완전히 대체함 리소스가 없으면 생성함
  • 대체하려고 넣는 리소스에 모든 내용이 없는데 대체하려고 하면 완전하지 않은 리소스로 대체가 된다.
• PATCH는 PUT과 다르게 부분적인 데이터만 변경할 때 사용할 수 있다.
  • PATCH를 지원하지 않는 경우가 있고 이럴 땐 POST를 쓴다.
• DELETE는 제거한다.

HTTP 메서드의 속성

• 호출해도 리소스를 변경하지 않는다. → 안전
• 변경이 일어남 → 안전하지 않음
• 안전은 계속 호출해 로그가 너무 많이 쌓여 나오는 장애와 같은 부분은 고려하지 않음
• 멱등 (Idempotent)
  • f(f(x)) = f(x)
  • 몇번을 호출하든 결과가 똑같은 경우 멱등이다.
  • GET, PUT, DELETE 는 멱등이다.
  • POST는 멱등이 아니다.
• 자동 복구 메커니즘을 쓸 수 있는지 구분하려고 멱등으로 구분
• 멱등이면 자동으로 재요청할 수 있음 → 결과가 바뀌지 않기 때문
• 멱등은 중간에 리소스가 변경되는 것까지는 고려하지 않는다.
• GET, HEAD, POST, PATCH 캐시 가능
• 실제로는 GET, HEAD 정도만 캐시로 사용
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음