[Day 121] REST API

grl pwr·2022년 9월 20일

📌 REpresentational State Transfer(REST)

자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미

아이스크림 샵을 운영한다고 가정했을 때, 그 날 재고가 있는 맛을 웹사이트에 표기한다고 해보자. 웹사이트는 cloud 베이스를 하는 server와 REST API로 통신할 것이다.

해당 소프트웨어가 관리하는 모든 것 ex) 문서, 그림, 데이터, 해당 소프트웨어 자체 등. 그 자원을 표현하기 위한 이름 ex) DB의 학생 정보가 자원일 때, 'students'를 자원의 표현으로 정한다

Roy Fielding의 박사학위 논문에서 최초로 소개됐습니다. 그는 HTTP의 주요 저자 중 한 명으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 점을 개선하고자 웹의 장점을 최대한 활용할 수 있는 아키텍처로 REST를 발표했습니다.

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)를 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것

자원 기반의 구조(Resource Oriented Architecture, ROA) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아케텍처를 의미한다

웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.

Cost-effective: HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
HTTP 표준에 의존한다는 것입니다. 즉, 형식에 의존적이며 XML, JSON, HTML 등을 사용할 수 있기에 REST API를 빠르고 lightweight하게 만듭니다. 이는 모바일 앱 프로젝트나 사물 인터넷 장치 등에 필요합니다.
REST API는 클라이언트와 서버가 독립적이다. 즉, REST 프로토콜은 데이터 저장소와 UI를 서버에서 분리합니다. 개발자는 프로젝트의 다른 영역에서 독립적으로 작업하고 필요에 따라 여러 개발자 환경을 시험해 볼 수 있다.
확장성과 유연성: REST API는 주로 클라이언트와 서버 간의 분리로 인해 빠르게 확장할 수 있습니다. 또한 개발자는 추가 작업 없이 REST API를 쉽게 통합할 수도 있다.
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다
scaleable and stateless: 웹 서비스의 사이즈가 커져도 쉽게 수정 가능하고 어떤 데이터가 어느 state에 있는지 신경쓰지 않아도 된다.
high performance due to caching: 웹 사이트 규모가 복잡해져도 high performance를 유지한다.

State가 부족: 대부분의 web application은 stateful mechanisms을 필요로 한다. 예를 들어 shopping cart가 있는 웹사이트에서 쇼핑을 한다고 가정했을 때, 실제 구매를 하기 전에 장바구니에 담긴 상품의 수를 알아야 합니다. State를 유지 관리해야 하는 이러한 부담은 클라이언트에 있으므로 클라이언트 application이 무겁고 유지 관리가 어렵습니다.
REST는 SOAP와 같은 보안을 부과하지 않습니다. 그렇기 때문에 REST는 공개 URL에는 적합하지만 클라이언트와 서버 간의 기밀 데이터 전달에는 적합하지 않습니다.