RESTful 이란

REST REpresentational State Transfer

• 리소스의 표현으로 해당 리소스의 상태를 주고 받는 것을 의미한다.
• HTTP URI를 통해 리소스를 명시하고, HTTP Method를 통해 리소스에 대한 적절한 상태의 CRUD를 적용하는 것을 의미한다.

장점

• HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능하다.
• REST API 요청과 응답에 의도하는 바가 명확히 드러나므로 쉽게 파악할 수 있다.

단점

• 사용할 수 있는 HTTP Method가 한정적이다.
• 구 브라우저가 지원하지 못하는 부분이 존재한다. (PUT/DELETE Method)

---

REST 6대 제약

1. Client-Server
   • 관심사의 분리 원칙에 따라 클라이언트는 요청을 전송하고 서버는 이 요청을 받아 처리 후 응답한다.
2. Uniform Interface
   • 일반적이고 간단할수록 일관성이 보장된다.
   • URI = Resource 명사 + HTTP 동사
3. Stateless
   • 클라이언트의 상태를 서버에 저장하지 않는다. (쿠키/세션 X)
   • 요청은 서버가 처리할 수 있는 충분한 정보를 지니고 있어서 그 자체만으로 의미를 짐작할 수 있어야 한다.
4. Cache
   • 서버 응답은 캐시에 보관해야 한다. 필요시 클라이언트는 메시지를 재전송해야 한다.
5. Layered System
   • 서버 응답은 직접 리소스를 가져오거나 캐시에서 꺼내어 전달한다.
   • Client-Server 간 여러 SW/HW가 올 수 있으므로 이렇게 해야 확장성이 좋아진다.
6. Code On Demand (optional)
   • REST 아키텍처는 계층적 레이어로 이루어지는데 레이어 각각은 자신과 인접한 레이어하고만 소통해야 한다.

REST API Richardson Maturity Model

Level 0 : Plain Old XML

• HTTP 프로토콜을 사용할 뿐 애플리케이션 상태를 나타내는 용도로 쓰지 않는다.
• 단순히 HTTP 메서드 한 개로 /getUser 같은 단일 URI에 요청/응답을 실어 나른다.

Level 1 : Resources

• 서로 다른 리소스를 분간할 능력을 갖추기 시작한 단계
• 엔드포인트마다 상이한 리소스를 나타내므로 여러 상이한 엔드포인트와 소통한다. POST resources/123 같은 URI를 사용하나 HTTP 메서드는 하나만 사용한다.

Level 2 : HTTP Verbs

• HTTP 동사를 리소스 명사와 고루 결합해서 REST 서비스를 온전히 제공하는 단계
• 완벽한 REST API의 경지는 도달하지 못한 상태

Level 3 : Hypermedia Controls

• HATEOAS로 애플리케이션 상태를 관리하는 단계
• 클라이언트가 다음에 할 수 있는 일이 무엇인지 귀띔하고 그 일을 하는 데 필요한 URI를 건네주는 경지

---

RESTful

• RESTful은 위의 제약 조건과 RMM을 만족하는 것을 의미한다.

RESTful API

• RESTful API는 RESTful 기반으로 작성된 API를 의미한다.

RESTful API Guide

• 리소스는 대문자보다 소문자를 사용해야 한다.
• 리소스의 도큐먼트 이름은 단수 명사를 사용해야 한다.
• 리소스의 컬렉션 이름은 복수 명사를 사용해야 한다.
• 자원에 대한 행위는 HTTP Method를 사용하되 URI에 표현해서는 안된다.

Method	URI	Description
POST	/resource	리소스 생성
GET	/resource	리소스 목록 조회
GET	/resource/:id	단일 리소스 조회
PUT	/resource/:id	리소스 수정
DELETE	/resource/:id	리소스 삭제

---