"REST가.. 뭐죠?" 라고 누군가 물었을 때 "그건 뭐뭐야" 라고 명료하게 대답해 줄 수 있으신가요? 저는 아무리 정리되어 있는 글을 여러개 봐도 '뭔 소리야?' 로 끝나더라구요. 설명들이 너무 추상적이라는 느낌을 받았습니다. 그래서 언제 어디에서 나온말인지부터 정리해보았습니다. 제가 이해하기 위해서요.
이 글을 읽고 난 후 "REST는 웹서비스 아키텍처를 만들기 위한 규칙 들이야~ 이런이런 규칙들로 이루어져 있어~" 정도만 되어도 소기의 목적을 달성했다고 생각합니다.
목차
- REST는 어디서 나왔는가
- REpresentational State Transfer 의 의미
- REST API란?
- HTTP를 사용하는 이유
❓ REST는 어디서 나왔는가
REST 라는 용어는 Roy Thomas Fielding 이 2000년에 발표한 박사학위 논문인 "Architectural Styles and the Design of Network-based Software Architectures"에서 처음으로 소개했습니다.
(논문 : https://ics.uci.edu/~fielding/pubs/dissertation/top.htm)
로이 필딩 형님이 개발할 당시에는 웹이 폭발적으로 성장하고 있었지만 ‘표준’이라는 개념이 미비했습니다. 그래서 직접 웹 개발의 표준을 만들고자 REST 라는 개념을 선보였습니다.
REST는 소프트웨어의 아키텍쳐를 만드는 하나의 방식으로써, 로이 필딩이 새롭게 제시한 소프트웨어 아키텍쳐 스타일인 것입니다.
소프트웨어 아키텍처 스타일이란, 특정한 원칙과 패턴을 기반으로 소프트웨어의 구조를 나타내는 것입니다.
이해를 조금 돕기 위해 비슷한 예를 들자면
우리가 1조 1항, 몇조 몇항 이라고 명시해 놓고 이를 "헌법"이라고 부르듯이,
소프트웨어를 만들기 위한 몇가지 규칙을 모아서 "REST" 라고 한 것입니다.
물론 REST를 지키지 않는다고 벌을 받진 않지만 가급적 표준으로서 이렇게 만들자~ 라는 것입니다.
그래서 로이 필딩이 말하는 REST 아키텍처 스타일의 원칙들은 무엇이 있을까요? 간략히 알아보겠습니다.
REST를 위한 제약사항
1. Client-Server (Client-Server)
2. Stateless (Client-Stateless-Server)
3. Cache (Client-Cache-Stateless-Server)
4. Uniform Interface (Uniform-Client-Cache-Stateless-Server)
5. Layered System (Uniform-Layered-Client-Cache-Stateless-Server)
6. Code-on-Demand (REST)
1. Client - Server 구조 사용 (Client-Server)
- 사용자 인터페이스에 대한 관심사와 데이터 저장에 대한 관심사 분리합니다.
- 각각의 요소가 독립적으로 발전할 수 있게 해준다는 것입니다.
2. Stateless (Client-Stateless-Server)
- '상태가 없는' 즉 서버에 상태정보를 저장하지 않는다는 뜻입니다.
- 모든 상태정보는 클라이언트쪽에 저장됩니다.
- 이 제약은 가시성(visibility), 신뢰성(reliability), 확장성(scalability) 을 가집니다.
가시성의 향상 : 요청에 대한 전체적인 특징을 파악하기 위해 해당 요청외에 다른 것들을 고려하지 않아도 됩니다.
신뢰성의 향상 : 부분적인 장애를 복구하기 위해서 고려해야할 것들이 많지 않기 때문에 복구가 용이해집니다.
확장성의 향상 : 서버가 요청에 대한 정보를 저장하지 않아도 되기 때문에 리소스를 확보할 수 있고, 요청에 대한 정보를 관리하지 않기 때문에 구현이 더욱 쉬워집니다.
- 단점은 서버측에 요청에 관한 정보가 저장되지 않기 때문에, 반복되는 일련의 요청이 발생하여 네트워크 성능을 저하시킨다는 것입니다. 또, 상태정보를 클라이언트측에 저장하기 때문에, 서버측의 일관된 제어를 받을 수 없다는 것입니다.
3. Cache (Client-Cache-Stateless-Server)
- 네트워크 성능을 향상시키기 위함입니다.
- 서버는 response에 해당 데이터가 cacheable한 지, non-cacheable한 지를 함께 명시합니다. cacheable 하다면 클라이언트는 해당 데이터를 재사용할 수 있는 권한이 생깁니다.
- 서버-클라이언트간 통신을 부분적으로 또는 완전하게 제거함으로써 통신 지연시간을 감소시킬 수 있고 이를 통해 네트워크 효율성(efficiency), 확장성(scalability), 사용자 만족도(user-perceived performance)를 향상시킬 수 있습니다.
- 단점은 캐시된 데이터가 최신 데이터와 달라져 신뢰성(reliability)이 저하될 수 있다는 것입니다. 그래서 정적 콘텐츠나 실시간성을 요하지 않는 동적콘텐츠(상품정보 등)에 대해서 캐시를 적용하는 것이 장점을 극대화할 수 있을 것입니다.
4. Uniform Interface (균일한 인터페이스) (Uniform-Client-Cache-Stateless-Server)
- 클라이언트와 서버간 통신하기 위한 인터페이스를 균일하게 만듭니다.
- REST 아키텍처 스타일이 다른 네트워크 기반 아키텍처 스타일과 구분되는 핵심적인 특징입니다.
- 인터페이스에 소프트웨어 공학의 원칙인 "일반성(generality)"을 적용함으로써, 전체적인 시스템 아키텍처는 단순화되고 상호작용의 가시성(visibility)은 향상됩니다.
- 단점은 효율성(efficiency)이 떨어진다는 것입니다. 클라이언트와 서버가 주고 받는 데이터가 해당 시스템에 특화된 형태가 아닌 표준화된 형태이기 때문입니다.
- REST 인터페이스는 대규모의 하이퍼미디어 데이터 전송을 효과적으로 하기 위하여 설계되었습니다. 그래서 웹이 아닌 다른 형태의 아키텍처에서는 최적이 아닌 인터페이스입니다.
- Uniform Interface 를 위해 4가지 추가적인 제약이 필요합니다.
1. identification of resources (자원 식별) : 각 자원은 고유한 식별자(URI)를 가져야 합니다.
2. manipulation of resources through representations (표현을 통한 자원 조작) : 자원은 다양한 표현을 가질 수 있으며, 클라이언트는 이러한 표현을 통해 자원을 조작합니다. 예를 들어, JSON 또는 XML 형식의 표현을 통해 자원의 상태를 전송하고 클라이언트는 이를 통해 자원을 생성, 읽기, 수정, 삭제할 수 있습니다.
3. self-descriptive messages (자기 기술적인 메시지) : 데이터는 자신이 어떻게 처리되어야 하는지에 대한 정보를 포함해야 합니다.
4. hypermedia as the engine of application state (HATEOAS, 애플리케이션 상태의 엔진으로서의 하이퍼미디어) : 클라이언트는 서버로부터 받은 하이퍼미디어를 기반으로 애플리케이션의 상태를 파악하고 다음 가능한 동작을 결정할 수 있어야 합니다. 이는 클라이언트와 서버 간의 상호 작용을 동적으로 만들어주고, 클라이언트는 상태 전이에 대한 사전 지식 없이 서버와 상호 작용할 수 있습니다.
5. Layered System (Uniform-Layered-Client-Cache-Stateless-Server)
- 시스템 구조가 여러 단계로 이루어진 경우 각 요소들은 인접한 요소 외에는 볼 수 없도록 하여 계층을 나눈 것입니다. 클라이언트 - 웹서버 - 웹 애플리케이션 서버(WAS) - DB 구조에서 클라이언트가 WAS나 DB에 접근하지 않는 것과 같은 내용입니다.
- 이를 통해 전체적인 시스템 복잡도를 낮추고 각 계층별 독립성을 향상시킵니다.
- 계층구조를 이용함으로써, 기존의 레거시(legacy) 시스템를 캡슐화하고, 새로운 서비스를 기존의 클라이언트로부터 보호합니다.
6. Code-on-Demand (REST)
- REST는 "클라이언트가 애플렛(Applet)이나 스크립트의 형태의 코드를 다운로드하고 실행해서 클라이언트 기능성이 확장되는 것"을 허용합니다. 상황에따라 허용할 수도 있고 그렇지 않을 수도 있는 선택적 제약사항입니다.
- 클라이언트측에서 사전에 구현(pre-implemented)해야 할 기능을 감소시켜 클라이언트를 단순화시킬 수 있습니다. 또, 배포 후에 기능을 다운로드할 수 있게 되는 것은 시스템의 확장성(extensibility)을 향상시킵니다.
- 하지만 가시성(visibility)을 감소시킵니다.
(이 제약은 현재는 보안등의 이유로 쓰이지 않습니다.)
이렇게 로이 필딩은 6가지 제약을 통해 REST를 정의하였습니다.
❓ 아니 그래서, REST, REpresentational State Transfer 가 무슨뜻이죠? REST의 의미
Representaional 표현
- 우리는 보통 JSON 파일, 사진, 동영상 그 자체를 데이터로 인식합니다. 하지만 로이 필딩은 자원(데이터)과, 그 자원을 표현하는 형식(XML, HTML, JSON 등) 으로 분리하여 생각했습니다. 각 자원은 고유한 식별자(URI)를 가지고 있습니다. 그래서 클라이언트와 서버는 데이터을 주고 받는 것이 아닌 데이터의 표현(XML, HTML, JSON 등) 을 주고 받는다고 본 것입니다.
State Transfer 상태 전송
- 로이 필딩은 하나의 웹페이지를 하나의 '상태'로 표현했습니다. 그래서 "현재 웹페이지(상태)에서 무언가를 누름 - State Transfer, 상태가 전이됨 - 다른 웹페이지(상태)로 바뀜" 이라고 말합니다.
이제 이 의미를 합쳐볼까요?
Representaional State Transfer
= 표현 상태 전송
= 데이터를 표현한 형식 전송
= XML등 페이지 전송
까놓고 보면 별거 없죠?
좀 더 일반화해서 말하자면 "URI로 식별 가능한 자원을, 자원의 표현(XML, HTML, JSON 등)으로 구분하여, 해당 자원의 상태(정보)를 주고 받는 것" 이라고 할 수 있습니다.
❓ 그렇다면 REST API는 무엇일까요?
정확히 말하면 RESTful API 가 맞습니다. REST를 따르는 API라는 뜻이죠. 하지만 그냥 통용해서 쓰는 듯 합니다.
- 클라이언트-서버 아키텍처에서 사용하는 인터페이스이고
- Stateless 상태정보를 서버에 저장하지 않고
- Cache 클라이언트에서 캐시가 가능하고
- Uniform Interface 균일한 규격을 가지고
- Layered System 계층구조에서도 사용 가능하고
- Code-on-Demand 필요 시 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 것.
❓ 왜 HTTP?
REST 이야기에서 빠지지 않고 나오는 것이 바로 HTTP 입니다. REST를 거의 HTTP 와 동률로 알고 있는 사람도 있지 않을까 생각합니다. REST 아키택처를 따르는 시스템은 대부분 HTTP 프로토콜을 사용합니다. 그 이유는 HTTP의 특성이 REST의 원칙과 상호 부합하기 때문입니다.
1. Uniform Interface
- HTTP는 Uniform Interface 제약 조건을 충족하는데, 이는 자원을 식별하고 표현하며, 메시지를 통해 자원을 조작하는 일관된 방식을 제공합니다. URI를 사용하여 자원을 식별하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 자원을 조작합니다.
2. Stateless
- RESTful API에서 무상태성은 각 요청이 독립적으로 처리되는데, HTTP는 기본적으로 무상태 프로토콜입니다. 각 요청은 서버가 클라이언트의 이전 상태를 기억하지 않고 독립적으로 처리되며, 이는 HTTP의 특징과 REST의 Stateless 제약 조건이 일치합니다.
3. Cache
- HTTP는 캐싱을 지원하여 리소스를 저장하고 재사용할 수 있습니다. 이는 RESTful API에서 자주 사용되는 기능 중 하나로, 클라이언트가 이전에 받은 응답을 캐시하여 네트워크 부하를 줄이고 응답 속도를 향상시킵니다.
4. Layered System
- HTTP는 중간 계층을 통한 중재를 지원하는데, 이는 RESTful 서비스에서 서버와 클라이언트 간의 중간 계층을 두어 시스템을 모듈화하고 확장성을 향상시킬 수 있도록 합니다.
5. Code-on-Demand (Optional)
- HTTP는 필요에 따라 클라이언트에게 서버에서 실행 가능한 코드를 전송하는 기능을 제공합니다. 이는 RESTful 서비스에서 클라이언트에게 동적인 코드를 전송함으로써 기능을 확장하고 업데이트하는 데 활용될 수 있습니다.
HTTP는 이러한 특징들을 통해 RESTful API를 설계하고 구현하는 데에 적합하며, RESTful 서비스의 표준 프로토콜로 널리 사용됩니다.
내용 참고
https://m.blog.naver.com/aservmz/222234406469
https://shoark7.github.io/programming/knowledge/what-is-rest
-------
이미지 출처
https://blog.naver.com/qkrdnjsrl0628/222779653191
https://springhow.com/restful-web-services-with-spring-boot/
https://www.linkedin.com/pulse/how-matured-your-rest-apis-murtaza-bagwala
https://www.researchgate.net/figure/Function-of-Code-on-Demand-Paradigm_fig2_259990495
'개념' 카테고리의 다른 글
| 의존성(Dependency)과 의존성 주입(Dependency Injection) 간단하게 이해하기 (0) | 2022.09.29 |
|---|---|
| 온프레미스(On-premise)와 클라우드 (0) | 2022.09.20 |
| Apache, Nginx, Tomcat, 웹서버, WAS, 정적컨텐츠, 동적컨텐츠 (0) | 2022.09.19 |
| C언어, 컴파일, 동적 컴파일, 정적 컴파일, 동적 라이브러리, 정적 라이브러리 (0) | 2021.03.29 |
댓글