REST(Representational State Transfer)는 효율적이고 신뢰할 수 있으며 확장 가능한 시스템을 가져오는 소프트웨어 아키텍처 설계 제약 그룹을 나타냅니다. 이러한 제약 조건에는 6가지가 있으며 REST를 이해하려면 제약 조건이 무엇이고 왜 존재하는지 알아야 합니다.
1. 클라이언트-서버 아키텍처 (Client-server architecture)
첫 번째 제약 조건은 클라이언트-서버 아키텍처(client-server architecture)입니다. 이 제약 조건은 담당 분야를 적절하게 분리합니다. 클라이언트는 사용자 인터페이스 문제를 관리하고 서버는 데이터 저장 문제를 관리합니다.
그 결과 우리는 하나의 REST 서비스에서 인터페이스가 어떻게 생겼는지 또는 무엇을 하는지 알 필요도 없고 신경 쓰지 않고도 다양한 클라이언트와 인터페이스를 제공할 수 있는 이식성이 뛰어난 시스템을 구축할 수 있습니다.
요컨대, 우리는 콘텐츠와 프레젠테이션 및 상호 작용을 완전히 분리합니다.
2. 상태 비보존 (Statelessness)
두 번째 제약 조건은 상태 비보존(statelessness)입니다. 클라이언트의 컨텍스트 또는 정보(일명 상태)는 서버에 저장하지 않습니다.
클라이언트는 자체 세션 상태를 추적할 책임이 있으며 클라이언트에서 보낸 모든 요청은 독립적이고 완전해야 합니다. 클라이언트의 세션 상태가 관련이 있는 경우 요청과 함께 전송되어야 하며 서버가 해당 상태를 저장해야 하는 경우 특정 시간 동안 데이터베이스 또는 유사한 서비스에 전달해야 합니다.
예를 들어 서버는 인증된 요청을 허용하기 위해 설정된 기간 동안 인증 토큰을 전달하도록 요청할 수 있습니다.
3. 캐시 가능성 (Cacheability)
세 번째 제약 조건은 캐시 가능성(cacheability)입니다. 일정 기간 동안 응답을 저장하는 것과 같은 캐싱은 웹 아키텍처 및 성능 최적화의 핵심 부분입니다.
모든 REST 응답은 캐시 가능 여부를 명확하게 표시하여 클라이언트 측에서 예상대로 캐싱이 작동하도록 해야 합니다. 이는 변경되지 않거나 변경될 가능성이 없는 응답을 캐싱하고, 거의 또는 주기적으로 변경된 응답을 합리적인 기간 동안 캐싱하고, 지속적으로 변경되는 응답에 대한 캐싱을 차단하는 것을 의미합니다.
4. 계층화된 시스템 (Layered system)
네번째 제약 조건은 계층화된 시스템(layered system)입니다. 시스템은 클라이언트가 서버에 직접 연결되어 있는지 또는 미러나 CDN과 같은 중개자에 연결되어 있는지 알 수 없고 신경 쓰지 않도록 설계되어야 합니다. 이는 확장성을 보장하고 보안에도 도움이 됩니다.
5. 코드 온 디맨드 (Code on demand)
제약 조건 다섯 번째, 요청에 의한 코드(code on demand)입니다. 서버는 기능을 확장 및 커스터마이징 하기위해 클라이언트 측 JavaScript 및 컴파일된 구성 요소의 형태로 실행 가능한 코드를 클라이언트로 전송할 수 있습니다.
하지만, code on demand는 REST에서 일반적으로 사용되는 방법은 아닙니다.
6. 통일화 된 인터페이스 (Uniform interface)
그리고 마지막으로 제약 조건 6번은 통일화된 인터페이스(uniform interface)로 4개의 추가 제약으로 나눠지기 때문에 실제로는 단일 제약이 아니라 4개의 제약이 더 있다고 봐야 합니다.
6.1 통일화 된 인터페이스는 요청에서 리소스 식별을 사용해야 합니다.
웹의 REST 시스템에서 URI는 요청을 보내는 데 사용되며 해당 URI는 찾고 있는 리소스를 지정합니다. 따라서 authors/mortens/bio와 같은 URI는 내 약력을 리소스로 요청합니다.
여기서 핵심은 리소스가 서버에 있는 데이터라는 것입니다.
REST가 반환하는 것은 서버 리소스와 다른 형식을 가질 수 있는 해당 리소스의 표현입니다. 따라서 리소스 데이터는 내 SQL에 테이블로 저장될 수 있지만 반환 표현은 JSON이나 XML 또는 심지어 HTML일 수 있습니다.
6.2 통일화 된 인터페이스는 표현을 통한 리소스 조작을 허용해야 합니다.
즉, 클라이언트에 리소스 표현이 있으면 해당 리소스를 수정하거나 삭제할 수도 있습니다. 다른 의미로 적절한 수준의 액세스 권한이 부여된 클라이언트는 서버에 저장된 내용을 제어할 수 있습니다.
6.3 통일화 된 인터페이스는 자체 설명 메시지를 발행해야 합니다.
이는 REST 데이터를 보내고 받는 데 모두 적용됩니다. 각 표현은 자체 데이터 형식을 설명해야 합니다. 따라서 JSON을 수신하는 경우 응답 메시지의 미디어 유형은 JSON으로 설정됩니다. 이 정보가 없으면 데이터를 안정적으로 구문 분석할 수 없습니다.
6.4 통일화 된 인터페이스는 애플리케이션 상태의 엔진으로 하이퍼미디어를 사용해야 합니다.
이는 클라이언트가 REST 리소스에 액세스 할 수 있게 되면 제공된 하이퍼링크를 통해 사용 가능한 모든 리소스와 메서드를 검색할 수 있어야 한다는 복잡한 표현입니다.
페이지 리소스를 요청하고 페이지 콘텐츠와 함께 반환 표시에는 사용 가능한 모든 리소스 및 메서드에 대한 하이퍼링크가 포함되어야 합니다. 즉, REST 서비스는 반환된 모든 리소스에 대한 자체 사용을 설명합니다.
여기까지 REST API의 제약조건을 알아봤으며, 웹 기반 API가 이러한 6가지 제약 조건을 충족하는 경우에만 RESTful API로 간주할 수 있습니다.
REST API의 개념과 동작 방식
우리는 휴대폰에서 좋아하는 소셜 미디어 앱을 열고, 태블릿에서 최신 뉴스를 읽고, 컴퓨터에서 여행 상품을 검색하거나, 스트리밍 서비스를 통해 좋아하는 프로그램을 시청합니다. 기술적인
jsonm.tistory.com
'IT 지식' 카테고리의 다른 글
| OpenAI CEO가 추천하는 모두가 읽어야 할 9가지 책 (0) | 2024.04.22 |
|---|---|
| 개발자 포털(Developer Portal) 구축 방안 (10) | 2023.06.15 |
| Web API의 특징과 장단점 (0) | 2023.06.12 |
| OAuth 2.0 (RFC 6749)의 목적, 인증 절차와 인증 방식 (0) | 2023.06.11 |
| Authentication과 Authorization 차이 (0) | 2023.06.11 |