HTTP(3/3)

HTTP Header

클라이언트와 서버가 요청 또는 응답으로 부가적인 정보(Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등)를 전송할 수 있도록 만들어 준다.

• field-name: OWS field-value OWS (OWS : 띄어쓰기 허용)
• field-name은 대소문자 구분을 하지 않는다.
• HTTP 전송에 필요한 모든 부가정보를 표현할 수 있다.
• 임의의 Header를 추가할 수 있다. 단, 서버가 값을 알고있어야 함
• 텍스트 (plain text)로 이루어져 있다.
• 각각의 헤더는 하나의 줄로 구분된다.

• 실제 HTTP Header 확인하는 방법
  - 실제 브라우저는 하나의 화면을 구성하기 위해 수많은 HTTP 통신을 진행한다!
  - 개발자도구(F12) → Network 탭 클릭 → Fetch/XHR 탭 클릭 → 우측 Header 정보
  

대표적인 HTTP Header

• 표현 헤더(Representation)
  • 실제 데이터를 전송할 때는 특정 형식으로 변환하여 보내게된다.
  • 리소스에 대한 표현 정보(어떤 데이터 형식으로 보낼지)를 나타낸다.
  • 요청, 응답에 모두 사용되는 Header이다.
  • 종류
    • Content-Type : 형식
      • 전송할 데이터의 미디어 타입, 문자 인코딩을 나타낸다.
      • text/html; charset=utf-8
      • application/json
    • Content-Encoding : 압축 방식
      • 데이터를 압축 후 Encoding 헤더를 추가하면, 읽는 쪽에서 해당 정보로 압축을 해제한다.
      • gzip
      • identity : 압축하지 않음을 나타낸다.
    • Content-Language : 언어

      • 데이터의 언어를 표현한다.

        ex) ko로 되어있으면 한글을 보여주고, en으로 되어있으면 영어로된 페이지를 보여줄 수 있다.

      • ko

      • en

    • Content-Length : 길이
      • 실제로는 표현 헤더가 아닌, 페이로드(Payload) 헤더이다.
      • byte 단위로 나타낸다.

• 컨텐츠 협상(Content Negotiation)
  • 클라이언트가 선호하는 표현을 요청한다.
  • 요청시에만 사용되는 Header이다.
  • 우선 순위가 존재한다.

    • Quality Values 줄여서 q 값을 사용한다.

    • 0 ~ 1 사이의 값이 존재하며 1에 가까울수록 우선순위가 높다.

    • Value가 1인 경우 생략이 가능하다.

      ex) Accept-Language: ko-KR,en-US;q=0.9,en;q=0.8

      → 서버에서 지원 가능하다면 우선순위를 기반으로 응답 데이터를 표현한다.

  • q가 생략되었다면 선언된 순서대로 우선순위를 가진다. ex2) Accept: application/json, text/plain, */* → application/json ⇒ text/plain ⇒ */*
    
  • 구체적으로 선언된 것이 우선순위가 높다. ex1) Accpet: 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 서버의 Software 정보
      • 응답에서 사용한다.
    • 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 값 전달
      • 만료기간(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 : 데이터가 마지막으로 수정된 시간
      • if-modified-since 요청이 오면 응답한다.
      • 304 (Not Modified) 상태코드와 함께 응답되면 수정되지 않았다는 의미
        • HTTP Message Body가 존재하지 않는다. 캐시 사용
      • 응답시 사용하는 헤더이다.
    • ETag : 캐시용 데이터에 날짜, 시간이 아닌 이름을 지정한다.
      • if-modified-since + Last-Modified 방식은 수정된 데이터가 같거나 캐시가 불필요한 경우를 구분하지 못한다.
      • 요청시 사용하는 헤더이다.

Restful API

REST를 잘 준수하는 API로 HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 통신을 통해 자원(Resource)을 관리한다. 자원은 고유한 URI로 식별되며, HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 다양한 작업을 수행하며 요청과 응답은 일반적으로 JSON 또는 XML 형식으로 이루어진다.
-> REST 기반으로 서비스 API를 구현한 것, HTTP API를 잘 설계하는 규칙이라고 정리할 수 있다.

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

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

• Maturity Model (성숙도 모델) 📚 A way to grade your API according to the constraints of REST - Leonard Richardson(Rest API 창시자) → REST의 제약 조건에 따라 API를 등급화하는 방법

Level 0

웹 서비스를 제공하기 위해 URL만 매핑해 놓은 상태
요청 예시(모든 요청이 단일 URI로 전송된다)

POST /operation
{
    "operation": "createUser",
    "data": {
        "name": "sparta",
        "password": "codingclub"
    }
}

Level 1

외부로 공개하려는 리소스에 대해서 의미있는 URL로 표현하기 시작한 단계
적절한 패턴을 가지고 작성 되었지만 HTTP의 메소드 별로 서비스를 구분하여 사용하고 있지는 않다.
즉, 서비스 형태나 작업의 종류에 맞추어 적절한 HTTP 메소드를 지정하고 있지 않다.
사용자의 요청을 GET, POST로 대부분 처리하고 에러를 반환한다.
요청 예시(리소스에 대해 분리된 엔드포인트를 가진다)

POST /users
{
    "name": "sparta",
    "password": "codingclub"
}

Level2
우리가 제공하고자 하는 리소스를 적절하게 용도와 상태에 따라서 HTTP Methods에 맞게 설계하고 서비스하는 단계.
만약 리소스의 상태가 읽기 용도로 사용되는 데이터라고 한다면 GET Method를 사용한다.
새로운 리소스를 추가하는 경우는 POST Method
기존 리소스의 상태를 변경하기 위해서는 PUT, PATCH Method
리소스를 삭제하고자 할 때에는 Delete Method를 사용하여 서비스의 상태를 표현한다.
RESTful Service의 DB에 저장된 리소스를 확인하고 이러한 데이터를 조작하기 위해서 CRUD와 매칭되는 HTTP Methods를 이용하여 서비스 하는 것을 Level2 단계라고 한다.
HTTP의 메소드를 이용하여 리소스의 상태를 구분하여 서비스 하게 되면 비슷한 이름의 URI라 하더라도 HTTP Method에 따라서 다른 형태의 서비스를 제공할 수 있게 된다.
요청 예시(HTTP Method 활용)

GET /users/123     // 특정 사용자 조회

POST /users        // 사용자 생성
{
    "name": "sparta",
    "password": "codingclub"
}

PUT /users/123     // 사용자 정보 수정
{
    "name": "java",
    "password": "spring"
}

DELETE /users/123  // 사용자 삭제

Level3

HATEOAS(Hypermedia As The Engine Of Application State)
회원 가입 후 회원 정보 수정은 어떻게 해야 하는지, 조회는 어떻게 해야 하는지
회원 조회를 하면서 그다음 단계로 진행할 수 있는 또 다른 리소스에 대한 정보는 어떠한 것이 있는지. 이러한 모든 정보를 같이 알려주는 기능을 HATEOAS라고 한다.

데이터를 가지고 그 다음 작업에서 어떠한 작업을 할 수 있는지 상태 정보를 함께 넘겨준다.
클라이언트 측에서는 서버가 제공하는 서비스를 일일이 찾는 수고를 겪지 않아도 된다.
엔드포인트만 가지고 있으면 서버가 제공할 수 있는 다음, 그 다음 URI값을 알 수 있다.
요청 예시(응답 내에 링크를 포함한다)

GET /users/123
{
    "id": 123,
    "name": "sparta",
    "links": {
        "self": "/users/123",
        "update": "/users/123",
        "delete": "/users/123"
    }
}

• 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

• 제공하는 데이터에 대하여 단수가 아닌 복수형태로 쓰는것이 일반적이다.
• 특정 유저를 찾고자 한다면 엔드포인트에 값을 추가한다.
  

ex) /user -> /users

ex) /users/1

7. User nouns for resources

• 모든 리소스는 가능하면 동사가 아닌 명사형태로 표시한다.
• API URI만 보고도 어떠한 API인지 파악할 수 있는것이 좋다.
  

8. For exceptions - define a consistent approach

• 일괄적인 엔드포인트를 사용하는것이 좋다.