REST(REpresentational State Transfer)와 API(Application Programming Interface)

📌 REST(REpresentational State Transfer)

• REST는 HTTP 기반의 소프트웨어 아키텍처 스타일입니다.
  
  
• REST는 "REpresentational(표현된) State(자원/데이터의 상태)를 Transfer(전달)"의 약자로 자원/데이터를 한눈에 알아볼 수 있도록 표현하고, 표현한 자원/데이터의 상태를 전달하는 것을 의미합니다.
  (요청의 상태만으로 해당 요청이 무슨 데이터를 요청하는 것인지 추론할 수 있는 상태)

📌 API(Application Programming Interface)

• 간단하게 설명하자면 소프트웨어끼리 데이터를 주고받기 위해 사용하는 일종의 요청방식을 API라 부릅니다.
  
  
• API의 요청 방식은 지정된 규칙 및 약속이 있습니다.

REST API

• REST의 특징을 기반으로 API를 구현하는 것을 REST API라 부릅니다.

• REST API는 소프트웨어의 요청이 어떠한 동작인지, 어떠한 정보를 원하는 것인지 해당 요청의 모습만으로도 추론이 가능한 요청 방식을 가지고 있습니다.

RESTful API

RESTful API는 REST 설계지침에 나온 6가지 조건을 모두 충족하여 설계된 API를 의미합니다.

📌 REST의 설계지침 6가지

1. Client-Server
2. Stateless
3. Cacheable
4. ⭐️Uniform Interface(까다로운 조건)
5. Layered System
6. Code On Demand

📌 인터페이스의 일관성(Uniform Interface)

1. 자원의 식별(identification of resources)
시간이 지나도 식별할 수 있는 고유한 식별자를 부여해야 합니다.
즉, 자원을 URI로 식별해야 합니다.

2. 표현을 통한 자원의 조작(manipulation of resources through representations)
클라이언트가 자원을 요청하면 서버는 요청한 자원을 표현하여 응답해야 합니다.
(자원의 표현은 문서, 파일, XML, JSON 등 이 이습니다.)

3. 자기 서술적 메시지(self-descriptive messages)
클라이언트와 서버에 오가는 요청/응답 메시지를 스스로 컴퓨터(스마트폰)에게 설명할 수 있도록 충분한 정보를 포함해야 합니다.

4. HATEOAS(Hypermedia As The Engine Of Application State)
하이퍼디미어(링크)를 통해 애플리케이션의 상태를 변경할 수 있어야 하며, 하이퍼디미어(링크)에는 그에 맞는 정보가 담겨있어야 합니다.

📌REST의 설계지침을 모두 따라야할까??

결론부터 말하자면 모두 따를 필요가 없습니다.

• 상황과 조건에 따라 RESTful한 방식의 API 설계/개발이 오히려 비효율적(구조적 또는 시간적, 비용적으로 비효율)일 수 있기 때문입니다.
  
  
• REST의 설계지침 중에서 Uniform Interface(특히 self-descriptive, HATEOAS)의 조건을 충족하기 어렵기 때문에 대부분의 REST API는 RESTful하지 않습니다.