REST(Representational State Transfer) API

Network

예요 2024. 7. 8. 19:31

① 개념

② 등장 배경

단순히 하나의 플랫폼만 지원하면 되었던 과거와 달리, 최근에는 여러 웹 브라우저 및 모바일 애플리케이션과의 통신에도 대응해야 하는 상황을 맞이했다.
플랫폼에 맞추어 새로운 서버를 만드는 수고를 들이지 않기 위해 범용적으로 사용성을 보장하는 서버 디자인이 필요해졌다.
클라이언트를 고려하지 않고 메시지 기반, XML, JSON과 같이 클라이언트에서 바로 객체로 치환 가능한 형태의 데이터 통신을 지향하게 되면서 서버와 클라이언트의 역할을 분리하게 되었다.

③ 유의사항

④ 구성요소

자원(Resource)
- 모든 자원에는 고유 ID가 존재하며 이는 서버에 존재한다.
- 자원의 고유 ID는 /function1/function1_1/function 와 같은 HTTP URI 이다.
행위(Verb)
- HTTP 프로토콜의 GET, POST, PUT, DELETE와 같은 Method를 사용한다.
표현(Representation od Resource)
- 클라이언트가 자원의 상태 및 정보에 대한 조작을 요청하면 서버는 이에 적절한 응답을 보낸다.
- 하나의 자원은 JSON, XML, TEST, RSS 등의 형태로 표현된다.

⑤ 특징

클라이언트/서버의 분리된 구조로 인한 의존성 감소
- 클라이언트는 사용자와 관련된 처리, 서버는 REST API를 제공함으로써 각각의 역할이 구분되고 일괄적인 인터페이스로 분리되어 작동할 수 있다.
무상태성
- 서버에서 작업에 대한 상태 정보를 기억할 필요가 없어지며 요청에 대한 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.
캐시 처리 가능
- HTTP라는 기존 웹 표준을 사용하는 덕분에 기본 웹에서 사용하는 인프라를 그대로 사용한다.
- 대량의 요청을 효율적으로 처리하기 위해 캐시를 사용하며 이를 통해 응답시간, 성능, 자원 이용률이 향상된다.
자체 표현 구조
- JSON을 이용한 메시지 포맷을 이용하여 직관적으로 기능을 이해할 수 있다.
계층화
- 클라이언트와 서버가 분리되어 있어 이 중간에 프록시 서버, 암호화 계층 등의 중간매체를 사용할 수 있어 자유도가 높다.
유니폼 인터페이스
- HTTP 표준을 따르는 전제하에 모든 플랫폼에서 사용이 가능하며 URI로 지정된 자원에 대한 조작을 가능하게 하는 아키텍처 스타일이다.
- 특정 언어나 기술에 종속되지 않는다.

⑥ 설계 목표

상호연동성 확보
- HTTP 및 URI 표준 기반이므로 직관적이고 사용이 간단하며 어디서든 동일하게 작동하는 것을 보장할 수 있다.
범용 인터페이스
- 어디서든 사용 가능한 범용 인터페이스를 제공하며 개발자는 비즈니스 로직만을 고민하면 된다.
각 컴포넌트들의 독립적인 배포
- 규격에 맞추어 개발된 컴포넌트들 사이에는 연동 하는데에 문제가 없다.
컴포넌트를 중계하는 역할
- REST 서버가 클라이언트와 엔드 서버 중간에서 중계 역할을 수행하므로 로드 밸런싱, 공유 메모리 등을 이용하여 확장성 및 성능을 향상시킬 수 있으면 보안 정책을 적용하기도 용이하다.

① 개념

② 목적

이해 및 사용이 쉬운 REST API를 만든다.
성능 향상보다는 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높인다.
RESTful하지 못한 경우
- CRUD 기능을 모두 POST Method로 처리하는 경우
- URL에 Resource, Id 외의 정보가 포함되는 경우

▷ 출처

728x90