25.03.27 TIL - HTTP(3)

 

 

 

목차

• HTTP
  • 1. HTTP Header
  • 2. 대표적인 HTTP Header
  • 3. Restful API
  • 4. RESTful API 설계 시 고려해야 할 사항들

 

 

HTTP

1. HTTP Header

    - 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 만들어줌.

 

2. 대표적인 HTTP Header

• 표현 헤더(Representation)
  • 실제 데이터를 전송할 때는 특정 형식으로 변환하여 보내게 됨.
  • 리소스에 대한 표현 정보를 나타냄.
  • 요청, 응답에 모두 사용되는 Header.
  • 종류
    • Content-Type : 형식
      • 전송할 데이터의 미디어 타입, 문자 인코딩을 나타냄.
      • text/html; charset=utf-8
      • application/json
    • Content-Encoding : 압축 방식
      • 데이터를 압축 후 Encoding 헤더를 추가하면, 읽는 쪽에서 해당 정보로 압축 해제.
      • gzip
      • identity : 압축하지 않음을 나타냄.
    • Content-Language : 언어
      • 데이터의 언어를 표현함.
      • ko
      • en
    • Content-Length : 길이
      • 실제로는 표현 헤더가 아닌, 페이로드(Payload) 헤더임.
      • byte 단위로 나타냄.
  • 컨텐츠 협상(Content Negotiation)
    • 클라이언트가 선호하는 표현을 요청.
    • 요청시에만 사용되는 Header.
    • 우선 순위가 존재함.
      • Quality Values 줄여서 q값을 사용.
      • 0 ~ 1 사이의 값이 존재하며 1에 가까울수록 우선순위가 높음.
      • Value가 1인 경우 생략 가능.
    • q가 생략되었다면 선언된 순서대로 우선순위를 가짐.
    • 구체적으로 선언된 것이 우선순위가 높음. 
    • 종류
      • Accept : 선호하는 미디어 타입.
      • Accept-Charset : 선호하는 문자 인코딩.
      • Accept-Encoding : 선호하는 압축 인코딩.
      • Accept-Lanuage : 선호하는 언어.
  • 일반 정보
    • 단순한 정보들을 나타내는 Header
    • 종류
      • From : 클라이언트 이메일 정보.
        • 잘 사용하지 않음.
      • Referer : 현재 요청된 페이지의 이전 웹 페이지 주소.
        • 유입 경로 파악 가능.
        • 요청 시 사용하는 Header
      • User-Agent : 클라이언트 애플리케이션 정보(PC, Mobile 브라우저)
        • 어떤 환경에서 주로 접속하는지 통계.
        • 어떤 종류의 환경에서 장애가 발생하는지 파악 가능.
        • 요청 시 사용하는 Header.
      • Server : 요청을 처리하는 ORIGIN 서버의 Software 정보.
        • 응답에서 사용.
      • Date : HTTP 요청이 발생한 날짜와 시간.
        • 응답에서 사용.
  • 특별 정보
    • 종류
      • Host : 요청한 도메인 정보.
        • 필수적으로 포함해야하는 Header.
        • 요청 시 사용.
      • Location : 생성된 리소스 URI, 리다이렉트 주소
        • 응답코드 3xx와 함께 응답되면 리다이렉트 주소.
        • 응답코드 201(Created)와 함께 응답되면 생성된 리소스의 URI.
      • Allow : 허용 가능한 HTTP Method
        • 405 (Method Not Allowed)와 함께 응답됨.
      • Retry-After : 다음 요청까지 대기해야하는 시간.
        • 503(Service Unavailable)와 함께 서비스가 언제까지 사용이 불가한지 알려줌.
        • 초단위, 날짜단위 모두 표현 가능.
  • 인증
    • 종류
      • Authorization : 클라이언트 인증 정보
        • 선택한 인증 방법에 따라 Value를 작성.
      • WWW-Authenticate : 리소스에 필요한 인증 방법.
        • 401(Unauthorized) 응답과 함께 사용.
  • Cookie
    • HTTP Stateless 특성을 가지고 있어서 상태를 매번 보내주어야 함.
    • Cookie를 사용하여 모든 요청마다 상태를 전달함.
    • 사용자 세션 관리, 광고 정보 트래킹에 많이 사용됨.
    • 종류
      • Set-Cookie : 서버에서 응답 시 클라이언트로 Cookie값 전달.
        • 만료기간(expire, max-age), 사용될 위치(domain, path)를 설정.
        • 주의
          • 항상 서버에 전달되니 최소한의 정보만 사용하여 트래픽을 최적화 시켜야 함.
          • 탈취당하기 쉬우니 보안에 민감한 개인정보 등은 저장하지 않음.
      • Cookie : 클라이언트가 서버에서 받은 쿠키를 Cookie 헤더를 통해 전송.
      • Secure : 헤당 헤더가 적용되면 https인 경우에만 쿠키를 전송.
        • 기본적으로 http, https 구분하지 않고 쿠키를 전송함.
        • HTTP + Secure 가 HTTPS.
      • HttpOnly : http 전송에만 사용.
        • 자바스크립트에서 쿠키를 접근하지 못하게 만듦.
      • SameSite : 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송.
  • Cache
    • 캐시가 없다면 같은 요청에 대한 응답 데이터가 같아도 매번 데이터를 새로 다운로드 받음.
    • 새로 다운로드 받는만큼 속도가 느려지고, 비용이 발생.
    • 종류
      • Cache-Control
        • 응답 시 사용하는 헤더.
        • Cache-Control : max-age
          • 캐시 유효 시간(초)
          • 캐시 유효 시간이 지나면 다시 서버를 통해 데이터를 응답받고 캐시 갱신.
        • Cache-Control : no-cache
          • 캐시 가능한 데이터지만, 서버에 검증하고 사용해야함.
        • Cache-Control : no-store
          • 보안에 민감한 데이터, 캐시하지 않음.
      • if-modified-since : 캐시로 저장된 데이터 최종 수정일.
      • Last-Modified : 데이터가 마지막으로 수정된 시간.
      • ETag : 캐시용 데이터에 날짜, 시간이 아닌 이름을 지정.

 

3. Restful API

    - REST를 잘 준수하는  API로 HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 통해 자원을 관리.

    - HTTP 메서드를 통해 다양한 작업을 수행하며 요청과 응답은 일반적으로 JSON 또는 XML 형식으로 이루어짐.

      → REST 기반으로 서비스 API를 구현한 것, HTTP API를 잘 설계하는 규칙.

 

💡REST(Representational State Transfer)란?
  - 자원(Resource)을 이름(Name)으로 구분하여 해당 자원의 상태(정보)를 주고받는 것을 의미.
  → URI를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE,PATCH 등)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것.

 

• 정리
  1. 리소스는 명사를 사용.
  2. 단수가 아닌 복수 형태를 사용.
  3. 만약, REST만으로 해결하기 어려운 경우라면 동사를 허용.
  4. 자원의 계층 관계를 슬래시(/)로 표현.
  5. 마지막 문자에는 슬래시(/)가 있으면 안됨.
  6. 언더바(_)가 아닌 하이픈(-)을 사용해야 함.
  7. 소문자를 사용해야 함.
  8. URI에 파일 확장자를 포함하면 안됨.
  9. CRUD 함수명은 사용하지 않고, HTTP Method를 활용해야 함.
  10. 정렬, 필터링, 페이징은 신규 API를 만드는것이 아닌 Query Parameter를 사용해야 함.

 

 

4. RESTful API 설계 시 고려해야 할 사항들

1. Consumer first
   • 개발자 중심의 설계방식보다 해당 API의 소비자 입장에서 간단하고 직관적인 API를 설계 해야함.
   • 위에서의 소비자는 엔드유저가 아닌 API를 사용 하고있는 또다른 시스템, 개발자 등을 얘기함.
2. Make best use of HTTP
   • HTTP Method와 Request, Response, Header와 같은 HTTP의 장점을 살려서 개발.
3. Request methods
   • 최소한 성숙도 모델 Level2로는 사용하여야 함.
4. Response Status
   • 각각 API 요청에 따라서 적절한 HTTP 상태코드가 전달되어야 함.
   • 성공했다, 실패했다가 아닌 왜 실패하고 성공 하였는지 함께 반환 시켜주어야 함.
5. No secure info in URI
   • URI에는 사용자의 정보를 포함해서는 안됨.
6. Use plurals
   • 제공하는 데이터에 대하여 단수가 아닌 복수형태로 쓰는것이 일반적.
   • 특정 유저를 찾고자 한다면 엔드포인트에 값을 추가한다.
7. User nouns for resources
   • 모든 리소스는 가능하면 동사가 아닌 명사형태로 표시함.
   • API URI만 보고도 어떠한 API인지 파악할 수 있는것이 좋음.
8. For exceptions - define a consistent approach
   • 일괄적인 엔드포인트를 사용하는것이 좋음.

•