REST 기초

 

 

REST란?

웹의 아키텍쳐 스타일.

 

아키텍쳐 스타일이란?

복수의 아키텍쳐의 공통된 성질, 양식, 규정, 독특한 방식 등으로 시스템의 아키텍쳐를 결정할 때 나침반이 된다.

추상화 단위: 구현(apache, FireFox, IE 등 엔진) < 아키텍쳐(브라우저, 서버, 프록시, HTTP, URI, HTML) < 아키텍쳐 스타일(REST)  

 

네트워크 시스템의 아키텍쳐 스타일은 클라이언트/서버(웹)이다.

REST는 클라이언트/서버 구조에서 나온 아키텍쳐 스타일에서 몇 가지 제약을 더해 만들어졌다. 제약은 복수의 컴포넌트들을 조합해 협력할 수 있게 해주기 때문에 중요하다. 

 

 

 

REST에서 중요한것: 리소스

리소스란?

웹 상에 존재하는 이름이 매겨진 자원으로, 여기서 이름이 바로 URI이다. 구체적인 리소스에 접근하는 방법을 알 필요 없이 짧은(간단한) URI로 리소스를 간단히 가리킬 수 있다(어드레스 가능성). 하나의 리소스에 복수의 URI를 가질 수 있지만 어느 게 정식 URI인지 알 수 없다.

서버와 클라이언트가 주고받는 구체적인 데이터를 'Resource Representation'이라고 부른다. 하나의 리소스는 복수의 표현을 가질 수 있고 URI의 리소스의 상태가 변화할 수 있다 그리고 상태가 변하면 표현도 변한다.

 

 

 

REST 스타일

1. 클라이언트/서버
   • 웹은 HTTP를 이용해 통신하는 클라이언트/서버 아키텍쳐 스타일을 사용하는데 이게 바로 REST이다.
   • 클라이언트와 서버가 분리되어 서버는 서버의 역할만 수행하고 복수의 서버를 가질 수 있고 서버를 확장할 수 있다. 
   • 클라이언트를 멀티 플랫폼(휴대전화,게임기 등)으로 구성할 수 있다.
2. 캐시
   • 한번 가져온 리소스를 저장해 클라이언트에서 돌려쓰는 방식으로 서버와의 통신 부하를 줄여 네트워크 통신 시간을 줄이고 효율성을 높여준다. 하지만 오래된 캐시를 이용해 정보의 신뢰성이 떨어지는 문제점도 있다. 
3. 무상태성 서버
   • 클라이언트의 애플리케이션 상태를 서버에서 가지고 있지 않아서 서버의 구현을 간략화할 수 있다.
   • 예외는 cookie로 세션관리를 하는 것이다. cookie는 상태성이 존재해서 REST에 반하지만 이건이 더 효과적인 방향인 경우가 있으니 선택적으로 최소화해서 사용해야 한다.  
4. 유니폼 인터페이스
   • 리소스에 대한 조작을 통일되고 한정된 인터페이스로 수행하는 아키텍쳐스타일이다.
   • 8가지의 메서드로 유형을 고정해 아키텍쳐를 간결하게 만든다.
   • 모든 서버가 같은 인터페이스를 채용해 클라이언트와 서버 구현의 중립성이 향상된다.
5. 계층화 시스템:
   • 유니폼 인터페이스의 이점 중 하나: 시스템 전체를 계층화하기 쉽다.
   • 클라이언트 서버를 계층화하여 서버와 클라이언트 간의 로드 밸런서를 설치해 부하를 분산시키거나 proxy 서버를 설치해 액세스를 제어할 때도 각 컴포넌트가 인터페이스를 HTTP로 통일하고 있기 때문에 가능하다. HTTP의 인터페이스를 가지고 있지 않더라고 웹 애플리케이션 서버를 중간에 두어 HTTP 인터페이스를 사용 가능하게 한다. 
6. 코드온디맨드:
   • 코드를 서버에서 다운받아 실행시키는 것이 아니고 서버에서 다운받은 것을 클라이언트 통신을 통해 보내 클라이언트에서 실행시킨다. 보통 자원을 요청하는 리퀘스트-리스폰스 관계가 아닌 js 같은 코드를 요청하고 응답받는 통신을 통해서 클라이언트에서 실행이 되고 확실한 자원을 주고받는 통신에 비해 응답받은 코드가 실행되면 어떻게 되는지는 알 수 없기 때문에 프로토콜 가시성이 떨어진다.  장점은 차후에 확장이 가능하고 새로운 기능을 추가할 수 있다는 점이다.
7. REST = ULCODC$SS -> 스타일을 모두 추가한 복잡한 아키텍쳐 스타일 이름을 REST로 명명했다. 
8. REST를 기반으로 아키텍쳐를 구축할 때에도 무리하게 다 구현하지 않고 몇 가지는 제외하더라도 상관없다.

 

 

 

REST의 하이퍼미디어 측면과 분산 시스템 측면 

1. 하이퍼미디어
   • 리소스를 링크로 연결되어 따라간다(작업)는 특징을 애플리케이션 상태 엔진으로써의 하이퍼미디어라고 한다.
   • 애플리케이션 상태는 작업에 의한 변화 한다. (그래서 엔진이라고 부른다)
   • (북마크 기능을 트위터에서 사용하는데 이걸 트위터에서도 같은 기능을 사용한다.)
   • 어떤 애플리케이션이 가지고 있는 리소스를 다른 애플리케이션에서도 URI만 알면 간단히 재사용할 수 있다.
   • 리소스를 링크로 연결해 하나의 애플리케이션으로 구성한다는 개념 -> 접속성 (REST의 근간을 이루는 사상)
2. 분산 시스템:
   • 링크를 이용해 애플리케이션을 실현하는 REST에서 리소스는 그 자체로 의미를 가진 데이터이고 자원화를 할 수 있는 크기(입도)가 커서 전체적인 성능 저하를 억제한다.
   • 각각 유니폼 인터페이스에 의해 아키텍쳐가 고정되고 추후에 변경될 가능성이 없어 호환성 문제가 발생하지 않고  마이너 버전업으로 하위 호환이 가능하다. 
   •  <-> 분산 오브젝트(RPC, CORBA, DCOM)는 네트워크를 통한 함수 호출로 통신 부하 심해지고 시스템의 성능 저하가 온다. 그리고 서버마다 다른 인터페이스를 사용해 버전업 시 호환성에 문제가 생긴다.