RestAPI

 

REST는 Representational State Transfer의 약자로, 네트워크 기반 애플리케이션을 디자인하기 위한 아키텍처 스타일

REST는 프로토콜이 아닌 HTTP와 URI(Uniform Resource Identifiers)와 같은 웹 표준을 어떻게 사용해야 하는지를 정의하는 제약과 원칙의 집합이라고 할 수 있다.

---

1. 리소스
 RESTful API에서는 모든 것이 리소스로 간주된다. 리소스는 문서, 이미지 또는 서비스와 같이 고유 식별자를 가진 모든 엔터티가 될 수 있다. 이러한 리소스는 URI(Uniform Resource Identifiers)에 의해 식별된다. 각 리소스는 웹상에서의 주소로 사용되는 고유한 URI를 가져야 한다.

2. HTTP 메서드
 RESTful API는 리소스에 대한 작업을 수행하기 위해 표준 HTTP 메서드를 사용한다.
     - GET: 리소스의 표현을 가져옴
     - POST: 새로운 리소스를 생성.
     - PUT: 기존의 리소스를 업데이트하거나 해당 리소스가 없으면 새로운 리소스를 생성.
     - DELETE: 리소스를 삭제.
     - PATCH: 리소스를 부분적으로 업데이트.

3. Representations
리소스는 JSON, XML, HTML 또는 일반 텍스트와 같은 다양한 표현을 가질 수 있다. 클라이언트와 서버는 리소스의 표현을 교환함으로써 통신한다. 클라이언트는 `Accept` 헤더를 사용하여 원하는 표현을 지정하고, 서버는 응답에서 `Content-Type` 헤더를 사용하여 요청된 형식의 리소스 표현을 반환한다.

4. Statelessness
클라이언트에서 서버로의 각 요청은 해당 요청을 이해하고 처리하는 데 필요한 모든 정보를 포함해야한다. 서버는 요청 사이에 클라이언트 상태에 대한 정보를 저장해서는 안 된다. 이는서버를 단순화하고 더 나은 확장성과 신뢰성을 가능하게 한다.

5. 클라이언트-서버 아키텍처
클라이언트와 서버는 네트워크를 통해 통신하는 별개의 엔터티. 이 분리는 클라이언트와 서버가 독립적으로 진화할 수 있도록 한다.

8. 캐시 가능성
서버에서의 응답은 명시적으로 캐시 가능하거나 캐시 불가능하게 표시될 수 있다. 캐싱은 클라이언트가 이전에 얻은 응답을 재사용함으로써 성능을 향상시킬 수 있다.

이러한 원칙과 설계 원리들은 RESTful API가 간단하면서도 효율적이며, 기존 웹 기술과의 호환성을 통해 분산 시스템의 구축을 용이하게 만든다.