HTTP 프로토콜

• 인터넷 상에서 데이터를 주고받기 위한 서버/클라이언트 모델을 따르는 프로토콜
• 어플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다.

• HTTP는 Connectless 방식으로 작동한다. 서버에 연결하고, 요청해서 응답을 받으면 연결을 끊어버린다.
• 장점
  • 불특정 다수를 대상으로 하는 서비스에 적합하다.
  • 수십만명이 웹 서비스를 사용하더라도 접속유지는 최소한으로 할 수 있기 때문에, 더 많은 유저의 요청을 처리할 수 있다.
• 단점
  • 연결을 끊어버리기 때문에 클라이언트의 이전 상태를 알 수가 없다. (stateless)
    • 클라이언트가 과거에 로그인을 성공하더라도 로그 정보를 유지할 수 없기 때문에, HTTP는 cookie를 이용해서 이 문제를 해결하고 있다.

HTTP 규격

https://datatracker.ietf.org/doc/html/rfc7231

HTTP 헤더

• 정의
  • Client와 Server가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해준다.
    • 부가적인 정보: 메시지 바디의 내용, 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등
    • 필수: 요청하는 호스트에 대한 호스트명 및 포트번호
• Content-Type
  • 표현 데이터의 형식
  • Message body가 어떤 타입인지, 어떻게 보여줘야 하는지 알려줌
  • 예) text/html; charset=utf-8, application/json, image/png
  • 예2) HTML파일을 보내는데 Content-Type을 text/plain으로 알려주면, 브라우저는 단순히 HTML코드 그대로를 화면에 보여준다.
• Content-Length
  • 바이트 단위의 표현 데이터 길이
  • 헤더 다음 몇 바이트만큼 읽어야 하는지 알려줌
  • Transfer-Encoding을 사용하면 Content-Length 사용하면 안 됨

Method

• 메서드는 요청의 종류를 서버에게 알려주기 위해 사용한다.
• GET: 정보를 요청하기 위해 사용한다.
• POST: 정보를 밀어넣기 위해 사용한다.
• DELETE: 정보를 삭제하기 위해 사용한다.

응답코드

• 서버는 응답코드로 서버의 상태를 알려준다.
• 200 OK
• 404 Not Found
• 500 Internal Error

Client request:
	GET /hello.txt HTTP/1.1
	Host: origin.example.com
	Content-Type: application/json
	Content-Length: 12481
	Expect: 100-continue
	// 빈 줄(empty line)
==============================================================
Server response:
 	HTTP/1.1 200 OK
 	Date: Mon, 27 Jul 2009 12:28:53 GMT
 	Server: Apache
 	Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
 	ETag: "34aa387-d-1568eb00"
	Accept-Ranges: bytes
	Content-Length: 51
 	Vary: Accept-Encoding
 	Content-Type: text/plain
	// 빈 줄(empty line)
	Hello World! My payload includes a trailing CRLF.

• Before sending the request message body, 100(continue) response를 기다릴 클라이언트는 MUST send an Expect Header field containing a 100-continue expectation.

JSON

• 인터넷에서 자료를 주고받을 때, 그 자료를 표현하는 방법이다.
• 자료의 종류에 큰 제한은 없고, 특히 컴퓨터 프로그램의 변수값을 표현하는데 적합하다.
• 자바스크립트의 구문 형식을 따르지만, 프로그래밍 언어나 플랫폼에 독립적이므로 많은 언어에서 이용할 수 있다.

/* 객체는 중괄호{} */
{
	"name": "식빵",
	"family": "웰시코기",
	"age": 1,
	"weight": 2.14
}
/* 배열은 대괄호[] */
"dog": [
  {"name": "식빵", "family": "웰시코기", "age": 1, "weight": 2.14},
  {"name": "콩콩", "family": "포메라니안", "age": 3, "weight": 2.5}
]

REST API

• REST API는 웹에서 데이터를 전송 및 처리하는 방법을 정의한 인터페이스를 말한다.
• 기본적으로 HTTP 프로토콜을 통해 통신한다.

구성요소

• Verb(행위) - HTTP Method
  • POST 데이터 생성
    • 요청 데이터 처리
      • Message Body를 통해 서버로 요청 데이터 전달 (서버한테 데이터 줄 테니까 요청 데이터 처리해줘!)
      • 서버는 요청 데이터를 처리, 메시지 받이를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
    • 주로 전달된 데이터로 신규 리소스 등록, 프르세스 처리에 사용한다.
      - POST는 모든 역할을 대신할 수 있지만, 조회 시에는 GET이 더 유리하다. 서버끼리는 서로 약속을 하고 있는데 GET으로 오면 캐싱을 하고, POST는 더 캐싱하기가 까다롭다.
  • GET 데이터 조회
  • DELETE 데이터 삭제
• Resource(자원) - URI를 의미함
  • URI: 인터넷 상의 자원을 식별하기 위한 문자열의 구성. (URL: 인터넷 상의 자원의 위치)
• Representation(표현)
  • Client가 Server에 자원에 대한 조작을 요청하면 Server는 이에 대한 적절한 응답을 해야 한다. 즉, 표현해야 하는 것이다.
  • 이러한 응답 메시지에는 JSON, XML 등의 포맷이 있고 최근에 JSON을 많이 쓰는 추세이다.

REST API의 특징

• Uniform Resource Identifier
  URI는 지정한 리소스에 대한 조작을, 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말한다.
• Stateless(무상태성)
  상태 정보를 따로 저장하고 관리하지 않는다. 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.
• Cacheable(캐시 가능)
  HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능하다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
• Self-descrptiveness(자체 표현 구조)
  REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.
• Sever-Client 구조
  REST Server는 API 제공, Client는 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 Sever와 Client에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어든다.
• 계층형 구조
  REST Sever는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.