반응형
RESTful Web Service 관련 Article
RESTFul Web Service 개요 #1 : 기본 개념 (http://alnova2.tistory.com/261)
RESTFul Web Service 개요 #2 : Resource Oriented Architecture
1. Resource-Oriented Architecture
REST는 architecture가 아니며 Design 범주이다. 따라서 매우 General한 의미이다.
Resource-Oriented Architecture는 가장 RESTful 한 Architecture라고 볼수 있다. ROA는 다음의 원리들을 가진다.
- Addressability
- Uniform interface
- Statelessness
- Connectedness
이중 Addressability와 Uniform Interface는 HTTP의 원리와 일치한다.
2. Resource와 URI
2.1 리소스란 무엇인가?
Resource는 그 자체로 표현 또는 참조가 가능한 중요한 무엇인가이다. 보통 리소스는 computer에 저장된 어떤 것이고 bit의 스트림으로 표현된다. 따라서 문서, 데이터베이스의 레코드 또는 특정 알고리즘의 결과라고도 할수 있다.
2.2 URI
URI는 Resource를 Resource일수 있도록 하는 것으로 Resource의 이름 또는 주소이다. URI는 다른 모든 프로토콜에 비하여 Web에 엄청난 장점을 주었는데 매우 단순한 방법으로 모든 것을 Labeling 할수 있도록 해주기 때문이다. URI는 구조를 가지고 있으며 Descriptive 하다.
Resource는 여러 URI로 표현 가능하며 URI는 하나의 Resource만 가르킬 수 있다. Resource의 표현은 이 Resource와 관계하는 다른 Resource에 대한 URI를 가질 수 있다. (Hypermedia)
2.3 Representation
URI 즉 Resource는 단순하게 데이터가 아니며 idea이다. Resource가 유용하게 하려면 이 idea가 bit로 표현되어야 한다. 이것을 Representation 이라고 부른다. 이는 Resource의 현재 상태(Status)에 대한 데이터 또는 유용한 정보이다. 만약 Resource 자체가 데이터이면 Representation은 데이터 그 자체가 될수 있다. 웹 서비스에서는 Resource는 XML, HTML, JSON, .... 등등으로 Representation이 가능하다.
Representation은 URI를 가지고 결정할수 있으며 (예: /id/status.xml, /id/status.json, /id/status.html 등으로) 혹은 HTTP 헤더의 Contents-negotiation 을 이용하여 결정할수 있다. (예: /id/status 에 HTTP request header에 ACCEPT: XML 또는 ACCEPT:JSON 등으로 표현)할수 있다. 하지만 URI가 기억되기 슆고 사람 또는 기계에 전달되기가 쉽다. Metadata(header내용)은 잃어버리기 쉽다.
3. ROA의 원리들
3.1 Addressability
Resource는 URI로 표현되며 URI는 그 자체로 Addressable 하다. 예를 들어 http://www.google.com/search?q=restful 은 어느 부분에서 불리든 항상 같은 Resource를 보여준다. 이 Resource가 addressable하지 않다면 http://www.google.com 으로 들어가서 입력을 해야 한다.
3.2 Statelessness
모든 HTTP 요청은 완벽한 고 립상태에서 발생한다. 즉 클라이언트가 HTTP 요청을 할때 서버에 그 요청을 수행할수 있는 모든 정보를 주어야 하며 이전의 Request에 의존해서는 안된다. 즉 서버의 가능한 어떤 상태도 Resource이고 URI를 가져야 한다. 이는 예를 들어 FTP와 HTTP와의 근본적인 차이이다. FTP는 Working Directory 개념이 있으며 HTTP에 비하여 훨씬 복잡하다. HTTP는 그 단순함이 Statelessness 특성으로부터 나온 것이다.
다음 그림은 Stateful한 검색 엔진의 예이다.
특정 상태가 다음의 상태를 결정한다. 다음은 Stateless한 검색엔진의 예이다.
어느 상태이든 관계없이 요청을 보낼수 있다.
Statelessness의 장점은 상태에 대한 저장을 하지 않으므로 확장성이 좋아진다. (Load-Balancing) 그리고 Cache하기에 적합한 구조이다. 클라이언트는 서버에 어떤 요청을 해야하는지를 가지고 있어야 하고 이는 어플리케이션 State이다. 서버의 상태는 리소스 이며 리소스는 Statelessness하다.
3.3 Link and Connectedness
Representation은 리소스의 상태 표현뿐만 아니라 hypermedia 형태를 가질수 있다. 즉 Document가 데이터뿐만 아니라 다른 리소스에 대한 Link를 가질수 있다. 즉 Representation = Data Stream + Links 가 될수 있다.
링크는 어플리케이션 상태 엔진을 제공 가능하다. (Hypermedia as the engine of application state) 특 링크를 통해서 상태가 표현이 될수 있으며 추적이 가능하게 되는 특성을 주게 된다. 이를 각 리소스가 connected 되어 있다고 말할 수 있다.
사람이 사용하는 웹은 잘 connected 되어 있으나 웹 서비스 자체는 그렇지 않다.
3.4 Uniform Interface
Resource에 대한 action은 다음의 HTTP method를 이용하며 주로 사용하는 메소드는 GET/DELETE/PUT/POST가 된다.
- GET: Resource의 현재 상태의 표현을 가져 온다.
- DELETE: 리소스를 삭제한다.
- HEAD: Representation의 metadata만 가져 온다. 하지만 Representation 자체는 가져 오지 않는다. 이를 통해서 Resource가 존재하는지를 확인 가능하며 Resource 표현 자체에 대한 정보를 획득 가능하다.
- OPTIONS: 클라이언트에 허락된 Resource에 대한 메소드를 가져온다. 예를 들어 클라이언트가 Authorization header를 채워서 OPTION으로 보낼 경우 서버는 GET/DELETE/PUT/HEAD를 Response 헤더의 ALLOW에 설정하여 보낸다. 만약 Authorization header가 Request에 없으면 GET/HEAD 만 ALLOW에 설정해서 보낼수도 있을 것이다.
- PUT: Representation을 Resource에 반영한다. 클라이언트가 지정한 Resource가 존재하지 않으면 Resource를 생성하고 반영한다.
- POST: POST는 두가지 기능을 한다. 1) 종속적인 Resource를 생성, 2) Resource에 Representation을 추가.
1) 종속적인 Resource 생성
만약 /weblogs/myweblog에 종속적인 Resource를 생성하면 POST를 통해서 /weblogs/myweblog/entry/1 이런 형태로 종속적인 Resource가 생성되고 HTTP response 결과는 201("Created")와 LOCATION에 새로 생성된 URI를 설정해서 보낸다. 요청을 보내는 URI는 parent 또는 factory URI로 불린다.
2) Resource에 Representation 추가
PUT은 Resource의 현재 Representation을 변경(대체)한다. 하지만 POST를 하게 되면 기존의 Resource의 Representation에 POST되는 Representation을 추가하게 된다.
3) Overloaded POST
이는 uniform-interface 원칙에 어긋나는 것으로 POST로 데이터를 전달하여 Processing하는 "Data-handling process"로 POST를 사용하는 경우이다. POST의 본래 HTTP method 목적과 맞지 않는 RPC-Style의 이용이다.
- Safety and Idempotence
1)Safety
클라이언트의 요청 메소드가 서버의 상태를 바꾸지 않는 것이다. 언제 호출하더라도 서버의 결과가 같은 것을 의미하며 GET과 HEAD 메소드가 이에 해당된다.
2) Idempotence
는 수학적으로 "A Operation that has the same effect whether you apply it once, or more than once"와 같이 정의되며 예를 들어 4*0*0*0=0이 되는 것과 4*1*1*1=4가 되는 것과 마찮가지이다. PUT과 DELETE가 이에 해당된다.
3) 왜 Safety와 Idempotence가 중요한가?
클라이언트가 unreliable한 네트워크에서 reliable한 HTTP request를 수행하기 위해서 필요한다. 예를 들어 GET Operation 수행시 클라이언트 쪽에서 Fail이 났을 경우 클라이언트가 다시 GET 요청하면 처음에 원했던 결과를 얻을수 있어야 하며 PUT Operation에서 클라이언트 쪽에서 Fail이 났을 경우 다시 PUT하면 원하는 Representation이 반영이 될수 있어야 하는 것과 같다. 이경우 서버에서 두번 PUT한다고 하여도 결과는 달라지지 않는다.
4) POST와 Safety & Idempotence
POST는 safety하지도 idempotence하지도 않다.
- Uniform interface가 중요한 이유
Uniform interface를 제공함으로 클라이언트가 메소드에 대하여 동일 기능을 할 것이라고 가정이 가능하며 메소드를 따로 찾을 필요가 없다. 모든 컴퓨터 시스템이 동일하게 사용 가능하다.
[이 포스트의 내용은 Restful web service의 책의 내용을 요약/재구성한 것임]
RESTFul Web Service 개요 #1 : 기본 개념 (http://alnova2.tistory.com/261)
RESTFul Web Service 개요 #2 : Resource Oriented Architecture
1. Resource-Oriented Architecture
REST는 architecture가 아니며 Design 범주이다. 따라서 매우 General한 의미이다.
Resource-Oriented Architecture는 가장 RESTful 한 Architecture라고 볼수 있다. ROA는 다음의 원리들을 가진다.
- Addressability
- Uniform interface
- Statelessness
- Connectedness
이중 Addressability와 Uniform Interface는 HTTP의 원리와 일치한다.
2. Resource와 URI
2.1 리소스란 무엇인가?
Resource는 그 자체로 표현 또는 참조가 가능한 중요한 무엇인가이다. 보통 리소스는 computer에 저장된 어떤 것이고 bit의 스트림으로 표현된다. 따라서 문서, 데이터베이스의 레코드 또는 특정 알고리즘의 결과라고도 할수 있다.
2.2 URI
URI는 Resource를 Resource일수 있도록 하는 것으로 Resource의 이름 또는 주소이다. URI는 다른 모든 프로토콜에 비하여 Web에 엄청난 장점을 주었는데 매우 단순한 방법으로 모든 것을 Labeling 할수 있도록 해주기 때문이다. URI는 구조를 가지고 있으며 Descriptive 하다.
Resource는 여러 URI로 표현 가능하며 URI는 하나의 Resource만 가르킬 수 있다. Resource의 표현은 이 Resource와 관계하는 다른 Resource에 대한 URI를 가질 수 있다. (Hypermedia)
2.3 Representation
URI 즉 Resource는 단순하게 데이터가 아니며 idea이다. Resource가 유용하게 하려면 이 idea가 bit로 표현되어야 한다. 이것을 Representation 이라고 부른다. 이는 Resource의 현재 상태(Status)에 대한 데이터 또는 유용한 정보이다. 만약 Resource 자체가 데이터이면 Representation은 데이터 그 자체가 될수 있다. 웹 서비스에서는 Resource는 XML, HTML, JSON, .... 등등으로 Representation이 가능하다.
Representation은 URI를 가지고 결정할수 있으며 (예: /id/status.xml, /id/status.json, /id/status.html 등으로) 혹은 HTTP 헤더의 Contents-negotiation 을 이용하여 결정할수 있다. (예: /id/status 에 HTTP request header에 ACCEPT: XML 또는 ACCEPT:JSON 등으로 표현)할수 있다. 하지만 URI가 기억되기 슆고 사람 또는 기계에 전달되기가 쉽다. Metadata(header내용)은 잃어버리기 쉽다.
3. ROA의 원리들
3.1 Addressability
Resource는 URI로 표현되며 URI는 그 자체로 Addressable 하다. 예를 들어 http://www.google.com/search?q=restful 은 어느 부분에서 불리든 항상 같은 Resource를 보여준다. 이 Resource가 addressable하지 않다면 http://www.google.com 으로 들어가서 입력을 해야 한다.
3.2 Statelessness
모든 HTTP 요청은 완벽한 고 립상태에서 발생한다. 즉 클라이언트가 HTTP 요청을 할때 서버에 그 요청을 수행할수 있는 모든 정보를 주어야 하며 이전의 Request에 의존해서는 안된다. 즉 서버의 가능한 어떤 상태도 Resource이고 URI를 가져야 한다. 이는 예를 들어 FTP와 HTTP와의 근본적인 차이이다. FTP는 Working Directory 개념이 있으며 HTTP에 비하여 훨씬 복잡하다. HTTP는 그 단순함이 Statelessness 특성으로부터 나온 것이다.
다음 그림은 Stateful한 검색 엔진의 예이다.
Statelessness의 장점은 상태에 대한 저장을 하지 않으므로 확장성이 좋아진다. (Load-Balancing) 그리고 Cache하기에 적합한 구조이다. 클라이언트는 서버에 어떤 요청을 해야하는지를 가지고 있어야 하고 이는 어플리케이션 State이다. 서버의 상태는 리소스 이며 리소스는 Statelessness하다.
3.3 Link and Connectedness
Representation은 리소스의 상태 표현뿐만 아니라 hypermedia 형태를 가질수 있다. 즉 Document가 데이터뿐만 아니라 다른 리소스에 대한 Link를 가질수 있다. 즉 Representation = Data Stream + Links 가 될수 있다.
링크는 어플리케이션 상태 엔진을 제공 가능하다. (Hypermedia as the engine of application state) 특 링크를 통해서 상태가 표현이 될수 있으며 추적이 가능하게 되는 특성을 주게 된다. 이를 각 리소스가 connected 되어 있다고 말할 수 있다.
사람이 사용하는 웹은 잘 connected 되어 있으나 웹 서비스 자체는 그렇지 않다.
3.4 Uniform Interface
Resource에 대한 action은 다음의 HTTP method를 이용하며 주로 사용하는 메소드는 GET/DELETE/PUT/POST가 된다.
- GET: Resource의 현재 상태의 표현을 가져 온다.
- OPTIONS: 클라이언트에 허락된 Resource에 대한 메소드를 가져온다. 예를 들어 클라이언트가 Authorization header를 채워서 OPTION으로 보낼 경우 서버는 GET/DELETE/PUT/HEAD를 Response 헤더의 ALLOW에 설정하여 보낸다. 만약 Authorization header가 Request에 없으면 GET/HEAD 만 ALLOW에 설정해서 보낼수도 있을 것이다.
- PUT: Representation을 Resource에 반영한다. 클라이언트가 지정한 Resource가 존재하지 않으면 Resource를 생성하고 반영한다.
1) 종속적인 Resource 생성
2) Resource에 Representation 추가
3) Overloaded POST
이는 uniform-interface 원칙에 어긋나는 것으로 POST로 데이터를 전달하여 Processing하는 "Data-handling process"로 POST를 사용하는 경우이다. POST의 본래 HTTP method 목적과 맞지 않는 RPC-Style의 이용이다.
- Safety and Idempotence
1)Safety
클라이언트의 요청 메소드가 서버의 상태를 바꾸지 않는 것이다. 언제 호출하더라도 서버의 결과가 같은 것을 의미하며 GET과 HEAD 메소드가 이에 해당된다.
2) Idempotence
는 수학적으로 "A Operation that has the same effect whether you apply it once, or more than once"와 같이 정의되며 예를 들어 4*0*0*0=0이 되는 것과 4*1*1*1=4가 되는 것과 마찮가지이다. PUT과 DELETE가 이에 해당된다.
3) 왜 Safety와 Idempotence가 중요한가?
클라이언트가 unreliable한 네트워크에서 reliable한 HTTP request를 수행하기 위해서 필요한다. 예를 들어 GET Operation 수행시 클라이언트 쪽에서 Fail이 났을 경우 클라이언트가 다시 GET 요청하면 처음에 원했던 결과를 얻을수 있어야 하며 PUT Operation에서 클라이언트 쪽에서 Fail이 났을 경우 다시 PUT하면 원하는 Representation이 반영이 될수 있어야 하는 것과 같다. 이경우 서버에서 두번 PUT한다고 하여도 결과는 달라지지 않는다.
4) POST와 Safety & Idempotence
POST는 safety하지도 idempotence하지도 않다.
- Uniform interface가 중요한 이유
Uniform interface를 제공함으로 클라이언트가 메소드에 대하여 동일 기능을 할 것이라고 가정이 가능하며 메소드를 따로 찾을 필요가 없다. 모든 컴퓨터 시스템이 동일하게 사용 가능하다.
[이 포스트의 내용은 Restful web service의 책의 내용을 요약/재구성한 것임]
반응형
