참고: https://dev-coco.tistory.com/97
Application Programming Interface의 약자로써, 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의한다.
따라서, 웹 API는 클라이언트와 웹 서버와의 게이트웨이와도 같다고 할 수 있다.
웹의 장점(HTTP 설계의 장점)을 최대한 활용할 수 있는 아키텍쳐로써,
"REpresentational State Transfer" 의 약자를 따서 REST가 되었다.
즉, 자원을 이름으로 구분하여 해당 자원의 상태 및 정보를 주고 받는 모든 것을 의미한다.
다시 말해서 ,자원의 표현에 의한 상태 전달을 의미한다.
REST는 어떠한 자원을 CRUD 하기 위해서, 자원 ( URI )으로, 행위 ( HTTP GET, POST ) 를 사용 하여 요청을 보내고, 요청을 위한 자원은 특별한 형태로 표현 된다. 이 세가지로 구성이 되어있다.
모든 자원에는 고유한 ID 가 존재하고, 이는 ‘URI’ 정보 이다. 이 자원은 서버에 존재한다. 따라서 클라이언트는 URI를 통해 해당 자원의 상태에 대한 처리를 서버에게 요청한다.
자원 ( URI )에 대한 처리를 어떤 HTTP 메소드로 할 것인가?
클라이언트와 서버가 데이터를 주고 받는 형태로써 JSON, XML 등등이 있다.
GET /members/delete/1
해당 방식은 REST의 규칙이 잘 지켜지지 않았다. URI가 정보의 자원을 표시하고 있지 않기 때문이다. delete와 같은 행위는 없애는 것이 좋다. 따라서
DELETE /members/1
과 같은 방식이 REST 스러운 방식이라고 할 수 있다.
한가지 예를 더보자면, ( 회원을 추가하는 상황이라고 가정해보자 )
GET /members/insert/2
회원을 추가하는데 GET메소드를 쓰지 않을 뿐더러, URI에 행위가 담겨져 있다.
POST /members/2
이렇게 하니 마음이 편해졌다.
CRUD를 잘 하기위해 ( REST는 자원을 CRUD하기 위해 탄생함 )
HTTP METHOD를 활용하는 것이다. 각각 POST, GET, PUT, DELETE 메소드로 CRUD를 처리할 수 있다.
자원을 가지고 있는 쪽 (서버) / 자원을 요청하는 쪽 (클라이언트) 구조로써,
REST 서버는 API 및 비즈니스 로직을 처리하고, 클라이언트는 사용자 인증이나, 세션, 로그인 정보들을 다루어서 역할을 확실히 구분하게끔 한다.
URI로 지정한 Resource에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미한다.
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
HTTP 프로토콜을 사용하므로 당연히 이전 상태를 기억하지 못한다.
HTTP가 가진 캐싱 기능을 사용할 수 있다. HTTP 프로토콜 표준에서 사용하는 Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 구현한다.
REST API의 표현만 봐도 어떤 처리를 하는지 알 수 있다.
클라이언트는 REST 서버에만 요청을 보낸다.
반면, REST 서버는 다중 계층으로 구성이 될 수 있다.
보안, 로드밸런싱, 암호화를 위한 계층을 추가할 수 있고, Proxy와 Gateway같은 네트워크 중간 매체를 사용할 수 있지만, Client는 이를 알지 못한다. 즉 중간서버와 통신하는지, REST 서버와 직접 통신하는지 알 수 없다.