01. REST이전

02. REST의 개념

2000년 로이 필딩(Roy Fielding)이 박사학위 청구 논문에서 REST(Representational State Transfer)를 소프트웨어 아키텍처 스타일로 제안
REST : Representational State Transfer
- 자원(resource)의 표현(representation) 에 의한 상태(State) 전달
  - 자원: 문서, 그림, 데이터, 소프트웨어 자체 등
  - 표현: 그자원을 표한하기 위한 이름 예) 영화=movies
  - 상태: 자원의 상태를 전달
    - PUT: 자원이 업데이트된 상태
    - POST: 자원이 새로 추가된 상태
    - GET: 자원을 읽은 상태
    - DELETE: 자원이 삭제된 상태

HTTP/0.9
- 1991년 월드와이드 웹 공식출발과 함께 시작
- method : GET
- Header가 없음
- GET /mypage.html
HTTP/1.0
- 1996년 11월 RFC 1945에 공개
- HTTP Header및 Content-Type추가로 HTML이외의 문서도 전송가능
- method: GET, POST
- GET /mypage.html HTTP/1.0
HTTP/1.1
- 1997년 1월 RFC 2068에서 처음 공개
- HTTP의 첮번째 표준
- method: GET, POST, OPTIONS, PUT, DELETE, TRACE
HTTP/2
- 2015년 5월 공식 표준화

REST기반으로 서비스 API를 구현한것
REST API의 특징
- Server-Client구조
- Stateless(무상태)
  - 세션이나 쿠키등을 별도로 관리하지 않습니다.
  - 클라이언트의 컨텍스트를 서버쪽에 유지하지 않습니다.
- Cacheable(캐시 처리 가능)
  - HTTP가 가진 캐싱 기능이 적용 됩니다.
  - HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
- Self-descriptiveness (자체 표현 구조)
  - REST 구조만 보아도 쉽게이해할 수 있는 자체 표현 구조를 가지고 있습니다.
- Layered System(계층화)
  - 클라이언트 입장에서는 REST Api서버만 호출한다.
  - Rest server를 다중 계층으로 구성
    - 보안, LB, 암호화, 인증등의 계층을 추가.
- Uniform Interface(인터페이스 일관성)
  - URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
장점
- API디자인에서 발생할 수 있는 문제를 최소화 한다.
- 서버와 클라이언트 역할을 명확하게 분리한다.
- API가 의도하는 바를 쉽게 파악할 수 있다.
- HTTP표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능하다.
단점
- 표준이 존재하지 않는다.
- 사용할 수 있는 메소드가 4가지 밖에 없다.

RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
- ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.
RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
- 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭된다.
RESTFUL의 목적은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이다.