[Essential Concepts] 자원의 이름으로 리소스를 식별하여 자원의 상태를 요청하거나 변경하는 REST API와 'RESTful' 하다

𐂂 🌐 HTTP란

웹서버와 클라이언트 간에 데이터를 주고 받기 위한 통신 규약을 말한다.

𐁍 Rest (Representational State Transfer)

자원(resource)의 이름으로 식별하여,
해당 자원의 상태(자원의 표현)를 전달하는 것을 의미한다.

즉, 각각의 자원은 고유한 식별자(URI)를 가지며,
클라이언트는 이 식별자(URI)를 사용하여 자원의 상태(표현)을 요청하거나 변경할 수 있다는 것을 의미한다.

ex. DB의 회원정보가 자원일 때, 'members/1'로 id가 1인 회원을 표현할 수 있다.

❓자원(resource)
: 웹 애플리케이션이 관리하는 모든 것을 말한다. (Entity와 유사한 개념)

❓자원의 표현(Representation)
: 요청되어지는 시점에서의 자원의 상태를 나타내는 데이터

⚠️ 자원의 상태는 JSON or XML을 통해 주고 받는 것이 일반적이다.
⚠️ REST는 HTTP 프로토콜을 그대로 활용한다.
  즉, REST는 네트워크 상 클라이언트와 서버 사이의 통신방식 중 하나이다.
  HTTP Method(GET, POST, PUT, DELETE)를 통해 자원의 상태(표현)를 요청하거나 변경한다.

🗿 ROA(Resource Oriented Architecture)
: 설계의 중심에 Resource가 있고,
HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍처를 의미한다.

🌝 REST의 장점
: HTTP 프로토콜의 인프라를 그대로 사용함으로 별도의 인프라 구축 필요 ❌
🍩 Stateless Protocol (🧩 무상태성)
🍩 Cacheable (캐시처리가능)
🍩 Uniform Interface (인터페이스 🧩 일관성 / Resource 조작에 대한)

: REST API 메시지가 의도하는 바를 명확하게 나타낸다.
: 서버와 클라이언트의 역할을 명확하게 분리한다.
: 다양한 클라이언트(멀티플랫폼)에서도 통신할 수 있다.

❓ API란 : 어떠한 방식으로 요청해야 어떠한 데이터를 받을 수 있을지에 대한 규격이다.

🌚 REST의 단점
: 표준이 존재하지 않는다.
: 사용할 수 있는 HTTP Methiod가 4가지 밖에 없다(GET, POST, PUT, DELETE)

𖠃 REST API 설계 규칙

🦁 도큐먼트: 객체 인스턴스나 데이터베이스 레코드와 유사한 개념
🦁 컬렉션: 서버에서 관리하는 디렉터리 리소스
🦁 스토어: 클라이언트에서 관리하는 리소스 저장소

(1) URI는 자원을 표현해야 한다.
- 동사보다는 명사
- 대문자보다는 소문자
- 도큐먼트 이름으로는 단수명사
- 컬렉션, 스토어 이름으로는 복수명사

(2) URI에 HTTP Method가 들어가면 안된다.
- 행위에 대한 동사표현이 들어가면 안된다. **

(3) URI 마지막 문자로 슬래시(/)를 포함하지 않는다.

(4) 가독성을 높이기 위해 하이픈(-)을 사용할 수 있다.

(5) URI에 파일확장자는 포함하지 않는다.

(6) 리소스 간 연관관계는 다음과 같이 표현한다.
- /리소스명/리소스ID/관계가 있는 리소스명

𖠃 REST 기반으로 웹서비스 API를 구현한 것을 RESTful 하다고 한다

🎯 목표:
일관적인 컨벤션을 통한 API의 🧩 이해도 및 호환성 향상