[Network] HTTP

hyoreal·2022년 8월 4일

Blocking/Non-Blocking REST API Sync/Async http

[Network]

목록 보기

2/2

HTTP Messages

HTTP (HyperText Transfer Protocol)
- HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜.
- HTTP 특징 : Stateless(무상태성)
HTTP Messages
- 클라이언트와 서버 사이 데이터 교환 방식
  - 요청(Requests)
  - 응답(Responses)
- HTTP Messages는 여러 줄의 텍스트 정보로 구성
- 구성파일, API, 기타 인터페이스에서 자동 완성
  - 따로 작성할 필요 X
요청/응답 공통 구조
- start line : 요청이나 응답의 상태. 항상 첫줄 위치. 응답에서는 status line
- HTTP headers : 요청 지정 및 메세지 본문 설명하는 헤더 집합
- empty line : 헤더와 본문을 구분하는 빈 줄
- body : 요청 관련 데이터나 응답 관련 데이터 및 문서 포함. 요청과 응답 유형에 따라 선택적 사용
- start line과 HTTP headers을 묶어 요청이나 응답의 head, payload는 body라 함.
요청 : 클라이언트가 서버에 보내는 메세지
- start line
  1. 수행 작업(GET,PUT,POST 등)이나 방식(HEAD, OPTIONS)를 설명하는 HTTP methods를 나타냄
  2. 요청대상 또는 프로토콜, 포트, 도메인의 절대경로는 요청 컨텍스트에서 작성
  - 요청 형식 HTTP methods
    - origin : ? 와 쿼리 문자열이 붙는 절대경로. POST, GET, HEAD, OPTIONS 등의 메서드 사용
    - absolute : 완전한 URL 형식, 프록시 연결하는 경우 GET메서드와 사용
    - authority : 도메인 이름과 포트번호로 이뤄진 URL의 authority component. HTTP터널 구축 경우 CONNECT와 사용
    - asterisk : OPTIONS 와 함께 * 하나로 서버 전체 표현
  1. HTTP 버전에 따라 HTTP message의 구조 달라짐. 따라서 start line에 버전 함께 입력
- Headers : 헤더이름(대소문자 구분X 문자열), :, 값을 입력. 값은 헤더에 따라 다름
  - General headers : 메세지에 전체 적용 헤더, body통해 전송되는 데이터와 관련X 헤더
  - Request headers : fetch를 통해 가져올 리소스, 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더. User-Agent, Accept-Type, Accept-LAnguage와 같은 헤더는 요청을 구체화. Referer 처럼 컨텍스트 제공, If-None처럼 조건에 따라 제약 추가 가능
  - Representation headers : body에 담긴 리소스의 정보(콘텐츠 길이, MIME타입 등)을 포함하는 헤더
- Body
  - Single-resource bodies(단일-리소스 본문) : 헤더 두개(Content-Type, Content-Length)로 정의된 단일 파일로 구성
  - Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보 가짐. 보통 HTML form과 관련
응답
- Status line
  1. 현재 프로토콜 버전(HTTP/1.1)
  2. 상태 코드 - 요청 결과 (200, 302, 404 등)
  3. 상태 텍스트 - 상태코드에 대한 설명
- Headers
  - General headers : 메세지 전체 적용 헤더, body를 통해 전송되는 데이터와 관련없는 헤더
  - Response header : 위치, 서버 자체 정보(이름, 버전) 와 같이 응답에 대한 부가적인 정보 갖는 헤더, Vary, Accept-Ranges와 같이 상태줄넣기 공간부족했던 추가정보제공
  - Representation headers : body에 담긴 리소스 정보(콘텐츠 길이, MIME타입) 포함 헤더
- Body
  - Single-resource bodies
    - 길이가 알려진 단일 리소스 본문은 두개의 헤더(Content-Type, Content-Length)로 정의
    - 길이를 모르는 단일파일 구성 단일리소스본문은 Transfer-Encoding이 chunked로 설정, 파일은 chuck로 나뉘어 인코딩.
  - Multiple-resource bodies : 서로 다른 정보 담고있는 body

Rest API

API
- HTTP 프로토콜 기반으로 요청응답에 따라 리소스를 주고받기위한 메뉴판 필요
- 이 메뉴판 역할을 API가 하기 때문에 잘 알아볼수 있게끔 작성해야함.
REST API
- 웹에서 사용되는 데이터나 리소스를 HTTP URI로 표현하고 HTTP 프로토콜을 통해 요청과 응답을 정의
- 웹 애플리케이션은 HTTP 메서드를 통해 서버와 통신
- 통신 중 요청과 응답을 할 때 일종의 규약
Rest 구성
- RESOURCE(자원) - URI
- Verb(행위) - HTTP METHOD
- Representations(표현)
REST 특징
- 유니폼 인터페이스
  - URI로 지정한 리소스 조작을 통일, 한정적인 인터페이스로 수행하는 아키텍처 스타일
- Stateless : 무상태성.
- 캐싱(Cacheable)
  - HTTP의 기존 웹 표준을 사용하기 때문에 기존 인프라 활용
  - Last-Modified / E-Tag 태그를 이용해 캐싱 구현 가능
- 자체 표현 구조
  - REST API 메세지만 보고 쉽게 이해 가능
- Client - Server
  - 클라이언트는 사용자인증, 세션, 로그인정보 들을 직접관리하는 구조
  - 서버는 API 제공으로 명확히 구분되어있어 의존성이 줄어듦
- 계층 구조
  - REST 서버는 다중 계층 구조로 구성 가능
  - 보안, 암호화, 로드밸런싱 계층 추가로 구조상 유연성을 둘 수 있음
  - 게이트웨이 등과 같은 네트워크 기반의 중간매체를 사용할 수 있음
좋은 REST API
- REST API작성 시 규칙 존재
- 로이 필딩이 제시한 REST 방법론을 더 실용적으로 적용하기 위해 레오나르도 리차드슨은 REST 성숙도 모델을 만듦
REST 성숙도 모델
- 0 ~ 3단계, 즉 4단계로 이루어짐
- 3단계까지 지키기는 어렵기때문에 2단계까지만 적용하더라도 좋은 API
- 0단계
  - 단순히 HTTP 프로토콜만 사용해도 가능
  - 좋은 REST API를 작성하기 위한 기본 단계
  - 현재 엔드포인트 /appointment
```
// Request 요청
POST /appointment HTTP/1.1
[헤더 생략]
{
  "date" : "2022-08-03",
  "doctor" : "허준"
}
```
```
// Response 응답
HTTP/1.1 200 OK
[헤더 생략]
{
  "slots" : [
    { "doctor" : "허준", "start" : "09:00", "end" : "12:00"},
    { "doctor" : "허준", "start" : "14:00", "end" : "18:00"}
  ]
}
```
- 1단계
  - 1단계에서는 개별 리소스와의 통신 준수
  - 모든 자원은 개별 리소스에 맞는 endpoint를 작성하고, 요청하고 받은 자원에 대한 정보를 응답으로 전달해야함
  - 요청하는 리소스가 무엇인지에 따라 다른 엔드포인트로 구분
  - 요청에 따른 응답으로 리소스를 전달할 때에도 사용한 리소스에 대한 정보와 함께 리소스 사용에 대한 성공 / 실패 여부를 반환해야함.
```
//Request 요청
POST /doctors/허준 HTTP/1.1
[헤더 생략]
{
  "date" : "2022-08-03"
}
```
```
//Response 응답
HTTP/1.1 200 OK
[헤더 생략]
{
  "slots: [
    { "id" : 123, "doctor" : "허준", "start" : "09:00", "end" : "12:00"},
    { "id" : 456, "doctor" : "허준", "start" : "14:00", "end" : "18:00"}
  ]
}
```
- 2단계
  - CRUD에 맞게 적절한 HTTP 메서드를 사용하는 것에 중점
  - GET메서드는 body를 갖지않기때문에 query parameter을 사용하여 필요한 리소스 전달, 서버의 데이터를 변화시키지 않는 요청에 적합
  - POST메서드는 요청마다 새로운 리소스를 생성
  - PUT메서드는 요청마다 같은 리소스 반환, 멱등한다.
  - PUT은 교체, PATCH는 수정
- 3단계
  - 마지막 단계는 HATEOAS(Hypertext As The Engine Of Application State)로 표현되는 하이퍼미디어 컨트롤 적용.
  - 요청은 2단계와 동일, 응답에는 리소스의 URI를 포함한 링크 요소를 삽입하여 작성.
  - 새로운 링크를 넣어 새로운 기능에 접근할 수 있도록 하는것이 3단계 중요 포인트
  - REST API 디자인 가이드
  - 구글 API 작성 가이드
  - 마이크로소프트 API 작성 가이드

Open API

Open API
- 누구에게나 열려있는 API이지만, 기관마다 정해진 이용수칙이 있고, 그 이용수칙에 따라 제한이 있을 수 있음
- 정부제공 공공데이터
- 날씨제공 Open API
- API를 이용하기 위해서는 API Key가 필요
- API Key : 서버의 문을 여는 열쇠