Rest API 라는 말은 많이 들어봤고 막연하게 사용할 때 느꼈을 때 (주로 Json 형태의)데이터를 주고 받기 위해 정한 규칙, 즉 프로토콜이라고 생각했었다. 그리고 찾아볼수록 많은 정의들을 찾을 수 있었고 다들 비슷한 이야기를 하지만 조금씩 표현이 다르고 내용이 다른 점도 존재하였다. 아마 내가 적어내린 것도 그중 일부가 되겠지만 내가 이해하기 쉬운대로 정리해보려고 한다.
REST == REpresentational State Transfer == 표현된 (자원의) 상태 전송
REST 자체는 API 작동 방식에 대해 조건을 부과하는 아키텍처
REST 6 가지 원칙
- Uniform Interface : 서버가 표준형식으로 정보를 전송함
- 자원에 대한 식별 => 리소스 식별자 사용
- 표현을 통한 자원에 대한 조작 => 리소스를 어떻게 사용할지에 대해 설명하는 메타데이터 추가
- 자기 서술적 메세지 => 리소스 설명하는 메타 데이터 추가
- 작업 위한 모든 리소스에 대한 정보 전달 => 표현에 하이퍼 링크 추가
- Stateless : 서버가 이전 요청과 독립적으로 모든 클라이언트 요청을 완료
- Caching : 응답 시간 개선 위해 사용하는 캐싱 제어 가능해야함
- Client-Server : 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처
- Hierarchical system : 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템
- Code on demand : 서버가 코드를 클라이언트에 전송하여 기능 확장 및 사용자 지정 가능
장점
- 확장성
- 유연성
- 독립성
단점
- 상황에 따라 제약조건이 비효율적일 수 있고 즉, 최적이 아닐 수 있음
- 어플리케이션에 필요한 정보가 아니라 표준화된 형식으로 데이터 전달할 수 있음
시스템을 통제할 수 있다고 생각한다면 REST를 준수하는것에 시간을 낭비하지 말라
- 로이 필딩 -
Ref)
논문을 통한 REST에 대한 고찰 - Parkito's on the way (shoark7.github.io)
반응형
댓글