[Spring] 스프링 입문 공부 !

HTTP (HyperText Transfer Protocol)

• 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되어있다.
• 다양한 형태의 데이터가 HTTP를 통해 전송된다.
• 여러 버전이 있으며, 그 중 대부분이 HTTP/1.1(TCP) 를 사용한다.
• HTTP는 클라이언트 to 서버(요청)뿐 만이 아니라 서버 to 클라이언트(응답)에도 사용되며, 서버 to 서버 간 데이터 통신에도 사용된다.
• HTTP 동작 순서
  • 클라이언트는 서버에게 Request(요청)을 보내고, 응답을 기다림
  • 서버는 요청에 대한 결과를 수행 후 결과를 Response(응답)한다.
    

HTTP의 메시지 구조

HTTP 요청 메시지

StartLine

• HTTP Method
  • Create(생성) : POST
  • Read(읽기) : GET
  • Update(수정) : PUT(전체), PATCH(일부)
  • Delete(삭제) : DELETE
    
    
• path
  • HTTP Request가 전송되는 대상, 절대 경로("/"로 시작하는 경로)
  • Query String(= Query Parameter)에 해당하는 값도 포함됨
    • ex) /search?keyword=sparta (Key-Value값)
  • GET의 경우 서버에 추가적인 데이터를 보내야 되면 Message Body가 아닌 Query String을 사용한다.
    
    
• HTTP Version
  • HTTP 버전을 나타낸다.

Header

• field-name: OWS field-value OWS (OWS : 띄어쓰기 허용) 구조를 가진다.
• field-name은 대소문자를 구분하지 않는다.
• 임의의 Header를 추가할 수 있다. (서버가 값을 알고있어야 함)
• 요청의 추가 정보들을 가지고 있다.
  • ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등

Empty Line

• 공백 한 줄
• 필수로 존재해야함

Message Body

• 실제 전송하는 데이터가 담겨있는 부분
  • html, 이미지, JSON 등 byte로 표현되는 모든 데이터 전송 가능
• 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.

HTTP 응답 메시지

Start Line

• HTTP Version
• Status Code
  • 요청이 성공했는지, 실패했는지 나타내는 코드
• Status Text
  • 코드와 함께 전달될 메시지

Header

• Response(응답)에서만 사용되는 헤더 값들이 따로 존재한다.
• Content-Type, Content-Length 는 밑에서 설명

Empty Line

• 공백 한 줄
• 필수로 존재해야함

Message Body

• 실제 전송하는 데이터가 담겨있는 부분
• 전송할 데이터가 없다면, 공백으로 존재한다.

HTTP Method 속성

• HTTP Method는 안정성(Safe), 멱등성(Idempotent), 캐시 가능성(Cacheable)속성을 가지고 있다.
• HTTP Method 별 속성표
  
• Optional은 Java의 Optional과 같이 있을 수 있다 라는 뜻.

1. 안정성 (Safe)

• GET(조회)은 안전하다
  • 저장된 데이터를 변환하지 않음
• POST, DELETE, PUT, PATCH 는 안전하지 않다.
  • 저장된 데이터를 생성, 삭제, 수정함

2. 멱등성 (Idempotent)

• 한 번 호출하거나, 수천번을 호출하거나 항상 결과는 같다.
  • GET -> 같은 결과가 계속 조회된다.
  • PUT -> 수정해서 대체된 후의 결과는 계속 같다.
  • DELETE -> 같은 요청을 여러번 해도 삭제된 결과는 같다.
  • POST -> 멱등성을 보장하지 않는다.
    - ex) 게시판 글쓰기, 회원가입 등
    
    
• 멱등성이 필요한 이유 : 요청이 실패한 경우 재시도 하기 위해 필요하다.
  • 항상 결과가 같다면 마음껏 재시도 가능
  • 만약 멱등하지 않다면, 중복 요청을 보내면 안됨
  • 복구 매커니즘에 사용한다.

3. 캐시 가능성 (Cacheable)

• 재사용을 위해 요청에 대한 응답을 저장할 수 있는가 ?
  • GET, HEAD, POST 메서드는 캐시가 가능하다.
  • 일반적으로 GET, HEAD 정도만 캐시로 사용된다.
• 캐시 (Cache) : 클라이언트가 한 번 요청했던 데이터를 매번 요청할 때마다 다시 전송할 필요가 없도록 웹 브라우저가 임시로 데이터를 저장하는 공간

HTTP 대표적인 header

표현 헤더 (Representation)

• 실제 데이터를 전송할 때 특정 형식으로 변환하여 보내게 된다.
• 요청, 응답에 모두 사용되는 Header이다.
  
  
• 종류 (Key : Value)
  • Content-Type : 형식
    • 전송할 데이터의 데이터 타입, 문자 인코딩을 나타낸다.
    • ex) text/html; charset=UTF-8
    • ex) application/json
      
      
  • Content-Encoding : 압축 방식
    • 데이터를 압축 후 Encoding 헤더를 추가하면, 읽는 쪽에서 해당 정보로 압축을 해제한다.
    • ex) gzip
    • ex) identity (압축하지 않음을 나타냄)
      
      
  • Content-Language : 언어
    • 데이터의 언어를 표현한다.
    • ex) ko (한국어)
    • ex) en (영어)
      
      
  • Content-Length : 길이
    • 실제로는 표현 헤더(Representation)가 아닌 페이로드 헤더이다.
    • byte 단위로 나타낸다.

컨텐츠 협상 (Content Negotiation)

• 클라이언트가 선호하는 표현을 요청한다.
• 요청시에만 사용되는 헤더이다.
  
  
• 선호 표현에 우선순위가 존재한다.
  • Quality Values를 줄여서 q값을 사용
  • 0~1 사이 값으로 존재하며, 1에 가까울수록 우선순위가 높음
  • Value가 1인 경우 생략 가능
  • ex) Accept-Language : ko-KR, en-EN; q=0.9, en; q=0.8
    • 서버에서 지원이 가능하다면 우선순위를 기반으로 우선순위를 기반으로 응답 데이터를 표현한다.
      
      
• q가 생략되었다면 선언된 순서대로 우선순위를 가진다.
  • ex) Accept : application/json, text/plain, */*
    • application/json > text/plain > */*
      
      
• 구체적으로 선언된 것이 우선순위가 높다.
  • ex) Accept : text/*, text/plain, text/plain;format=flowed, */*
    • text/plain;format=flowed > text/plain > text/* > */*
      
      
• 종류
  • Accept : 선호하는 미디어 타입
  • Accept-Charset : 선호하는 문자 인코딩
  • Accept-Encoding : 선호하는 압축 인코딩
  • Accept-Language : 선호하는 언어

일반 정보

• 단순한 정보들을 나타내는 Header이다.
  
  
• 종류
  • From : 클라이언트 이메일 정보
    • 잘 사용하지 않는다.
      
      
  • Referer : 현재 요청된 페이지의 이전 웹 페이지 주소
    • 유입 경로 파악 가능
    • 요청시 사용하는 Header
      
      
  • User-Agent : 클라이언트 애플리케이션 정보 (PC, Mobile)
    • 어떤 환경에서 주로 접속하는지 통계
    • 어떤 종류의 환경에서 장애가 발생하는지 파악 가능
    • 요청시 사용하는 Header
      
      
  • Server : 요청을 사용하는 ORIGIN 서버의 소프트웨어 정보
    • 응답에서 사용한다.
      
      
  • Date : HTTP 요청이 발생한 날짜와 시간
    • 응답에서 사용한다.

특별 정보

• 종류
  • Host : 요청한 도메인 정보
    • 필수적으로 포함해야 하는 Header
    • 요청시 사용
      
      
  • Location : 생성된 리소스 URI, 리다이렉트 주소
    • 응답코드 3xx와 함께 응답되면 리다이렉트 주소이다.
    • 응답코드 201(Created)와 함께 응답되면 생성된 리소스의 URI 이다.
      
      
  • Allow : 허용 가능한 HTTP Method
    • 405(Method Not Allowed)와 함께 응답한다.
    • ex) Allow : GET, POST
      
      
  • Retry-After : 다음 요청까지 대기 해야하는 시간
    • 503(Service Unavailable)과 함께 서비스가 언제까지 사용이 불가한지 알려준다.
    • 초 단위, 날짜 단위 모두 표현이 가능하다.

인증

• 종류
  • Authorization : 클라이언트 인증 정보
    • 선택한 인증 방법에 따라 Value를 작성한다.
      
      
  • WWW-Authenticate : 리소스에 필요한 인증 방법
    • 401(Unauthorized) 과 함께 사용된다.

Cookie

• HTTP는 Stateless(무상태) 특성을 가지고 있어서 상태를 매번 보내주어야 한다.
• Cookie를 사용하여 모든 요청마다 상태를 보낸다.
• 사용자 세션 관리, 광고 정보 트래킹에 많이 사용된다.
  
  
• 종류
  • Set-Cookie : 서버에서 응답 시 클라이언트로 Cookie 값 전달
    • 클라이언트가 요청할 때마다 서버에 보낼 Cookie를 받는 것
    • 만료 기간(expire, max-age), 사용될 위치(domain, path)를 설정할 수 있다.
    • 주의
      • 항상 서버에 전달되니 최소한의 정보만을 사용해 트래픽을 최적화 해야 됨
      • 탈취를 당하기 쉬워 보안에 민감한 정보를 저장하지 않는다.
        
        
  • Cookie : 클라이언트가 서버에서 받은 Cookie를 쿠키 헤더를 통해 전송
    
    
  • Sequre : 해당 헤더가 적용되면 https인 경우에만 쿠키를 전송
    • 기본적으로 http, https를 구분하지 않고 쿠키를 전송한다.
    • HTTP + Sequre = HTTPS
      
      
  • HTTP Only : http 전송에만 사용된다
    • JS에서 쿠키를 접근하지 못하게 만든다.
      
      
  • SameSite : 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다.

Cache

• 캐시가 없다면 같은 요청의 응답 데이터가 같아도 매번 데이터를 새로 다운로드 받는다.
• 매번 새로 다운로드 받는 만큼 속도가 느려지고 비용이 발생한다.
  
  
• 종류
  • Cache-Control
    • 응답시 사용하는 헤더
      
      
    • Cache-Control : max-age
      • 캐시 유효 시간
      • 유효 시간이 지나면 다시 서버를 통해 데이터를 응답 받고 캐시를 갱신한다.
        
        
    • Cache-Control : no-cache
      • 캐시 가능한 데이터지만 서버에 검증 하고 사용해야 된다.
        
        
    • Cache-Control : no-store
      • 보안에 민감한 데이터, 캐시하지 않는다.
        
        
  • if-modified-since : 캐시에 저장된 데이터의 최종 수정일
    • 요청시 사용한다.
      
      
  • Last-modified : 데이터가 마지막으로 수정된 시간
    • if-modified-since 요청이 오면 응답
    • 304 (Not Modified)와 함께 응답되지 않으면 수정이 안됨을 의미
      • HTTP Message Body가 존재하지 않는다.
    • 응답시 사용한다.
      
      
  • ETag : 캐시용 데이터에 날짜, 시간이 아닌 이름을 지정한다.
    • if-modified-since + Last-modified 는 수정된 데이터가 같거나 캐시가 불필요한 경우를 구분하지 못한다.
    • 요청시 사용하는 데이터

★ Restful API

• 즉, REST 기반으로 서비스 API를 구현한 것이며, HTTP API를 잘 설계하는 규칙이다.
  
  
• REST란 ?
  • 자원을 이름으로 구분해 해당 자원의 상태(정보)를 주고 받는 것을 의미
  • URI를 통해 자원을 명시하고 HTTP Method를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 REST라고 한다.
    
    
• Restful 정리
  1. 리소스는 명사를 사용해야 한다.
  2. 단수가 아닌 복수를 사용해야 한다.
  3. 만약, REST만으로 해결하기 어려운 경우 동사를 허용한다.
  4. 자원의 계층 관계를 슬래시(/)로 표현한다.
  5. 마지막 문자에는 슬래시(/)가 있으면 안된다.
  6. 언더바(_)가 아닌 하이픈(-)을 사용해야 한다.
  7. 소문자를 사용해야 한다.
  8. URI에 파일 확장자를 포함하면 안된다.
  9. CRUD 함수명은 사용하지 않고, HTTP Method를 활용해야 한다.
  10. 정렬, 필터링, 페이징은 새로운 API를 만드는게 아닌 Query Parameter을 사용해야 한다.