[Spring] REST(Representational State Transfer) API

다른 소프트웨어로부터 지정된 형식으로 요청, 명령을 받을 수 있는 수단을 API(Application Programming Interface)라고 하는데
REST API는 Rest 아키텍처 스타일의 디자인 원칙을 준수하는 API

 

SOAP과 REST 비교

REST는 과거 SOAP(Simple Obejct Access Protocol)을 대체하는 것으로 SOAP 과 REST 의 주요 차이는 프로토콜 여부

SOAP은 표준 프로토콜로 복잡성과 오버헤드를 증가시키는 빌트인 룰을 적용하기 때문에 페이지 로드 시간이 길어질 수 있지만,

이러한 표준은 보안과 안정적인 데이터베이스 트랜잭션을 포함함

REST는 유연한 구현을 제공하는 가이드라인을 제시하기 때문에 SOAP 보다 경량화되어있어 모바일 어플리케이션 등에 이상적

 

REST API 설계

RESTful API는 Resource 상태에 대한 표현을 요청자에게 전송

여기서의 Resource 상태라함은 URI에 정보의 자원을 표현해 식별이 가능해야함을 뜻하고,

/* 예시: 직원 중 인사팀의 여자 조회 */
http://(도메인)/employee/HR?sex=female

이 요청은 HTTP를 통해 이루어지며 자원에 대한 행위는 HTTP method(GET, POST, PUT, PATCH, DELETE)로 표현

GET	데이터를 조회(READ)
POST	데이터를 추가(CREATE)
PUT	데이터를 변경(UPDATE) - 모든 데이터 항목을 변경
PATCH	데이터를 변경(UPDATE) - 일부 데이터만 변경
DELETE	데이터를 삭제(DELETE)

 

REST 디자인 원칙

Uniform Interface

균일한 인터페이스

요청이 어디에서 오는지와 관계없이 동일한 리소스에 대한 모든 API 요청은 동일하게 보여야 함

REST API는 사용자 정보의 데이터 조각이 하나의 URI에 속함을 보장해야하며 클라이언트가 필요로 하는 모든 정보를 포함해야 함

 

Client-server decoupling

클라이언트-서버 디커플링

클라이언트와 서버 애플리케이션은 서로 완전히 독립적이여함

클라이언트 애플리케이션이 알아야하는 유일한 정보는 요청됭 리소스의 URI이며 다른 방법으로는 서버 애플리케이션과 상호작용할 수 없음

서버 애플리케이션은 HTTP를 통해 요청된 데이터에 전달하는 것 외에 클라이언트 애플리케이션을 수정하지 않아야 함

 

Statelessness

무상태성

각 요청에서 처리에 필요한 모든 정보를 포함해야 함

REST API는 서버측 세션을 필요로 하지 않으며, 서버 애플리케이션은 클라이언트 요청과 관련된 데이터를 저장할 수 없음

즉, 서버는 클라이언트의 request에 response 하고나면 클라이언트의 정보를 잊음

 

Cacheability

캐싱 가능성

가능하면 리소스를 클라이언트 혹은 서버측에서 캐싱할 수 있어야 하며 서버 응답에는 전달된 리소스에 대한 캐싱이 허용되는지 여부의 정보도 포함해야함

 

Layered system architecture

계층 구조 아키텍쳐

호출과 응답이 서로 다른 계층을 통과해야 함

클라이언트와 서버 애플리케이션은 서로간에 직접 연결된 것이 아닌 통신루프에 다수의 서로 다른 중개자가 있을 수 있음

REST API는 중개자와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야 함

 

Code on demand

코드 온디맨드

일반적으로 정적 리소스를 전송하지만 특정한 경우에는 응답에 실행 코드를 포함해야 하며 이러한 경우 코드는 요청 시에만 실행되어야 함