스트리밍 리소스가 RESTful 패러다임에 어떻게 들어 맞습니까?

Question

RESTful 서비스를 사용하면 리소스를 생성, 읽기, 업데이트 및 삭제할 수 있습니다. 이 방법은 데이터베이스 자산과 같은 것을 처리 할 때 모두 잘 작동하지만 스트리밍 데이터로 변환하는 방법은 무엇입니까? (또는 그럴까요?) 예를 들어, 비디오의 경우, 각 프레임을 한 번에 하나씩 쿼리해야하는 리소스로 취급하는 것은 어리석은 것처럼 보입니다. 오히려 소켓 연결을 설정하고 일련의 프레임을 스트리밍합니다. 하지만 이것이 RESTful 패러다임을 깨뜨릴 수 있습니까? 스트림을 되감거나 앞으로 감을 수 있도록하려면 어떻게해야합니까? 이것이 RESTful 패러다임 안에서 가능합니까? 따라서 : 스트리밍 리소스가 RESTful 패러다임에 어떻게 들어 맞습니까?

구현과 관련하여 이러한 스트리밍 데이터 서비스를 만들 준비가되어 있으며이를 "최선의 방법"으로 수행하고 싶습니다. 나는이 문제가 전에 해결되었다고 확신한다. 누군가가 좋은 재료를 가르쳐 줄 수 있습니까?

Answer 1

저는 실제로 RESTful streaming에 대한 자료를 찾을 수 없었습니다. 결과는 대부분 다른 서비스로 스트리밍 위임하는 것입니다 (나쁜 해결책은 아닙니다). 따라서 직접 해결할 수 있도록 최선을 다할 것입니다. 스트리밍은 도메인이 아니지만 2 센트를 추가하려고합니다. (미디어 리소스 (메타 데이터) 매체에

액세스/자체를 스트림에

이

1. 액세스 진 : 스트리밍의 측면에서
   , 나는 우리가 두 개의 독립적 인 부분으로 문제를 분리 할 필요가 있다고 생각 데이터) 미디어 리소스에

1) 액세스
이 매우 간단하고 깨끗하고 편안하고 방법으로 처리 할 수 ​​있습니다. 개별 스트림도

GET /media/ 

<?xml version="1.0" encoding="UTF-8" ?> 
<media-list uri="/media"> 
    <media uri="/media/1" /> 
    <media uri="/media/2" /> 
    ... 
</media-list> 

... 그리고 : : 예를 들어, 이제 우리는 우리가 스트림의 목록에 액세스 할 수있는 XML 기반의 API있을 것이라는 점을 가정 해 봅시다

GET /media/1 

<?xml version="1.0" encoding="UTF-8" ?> 
<media uri="/media/1"> 
    <id>1</id> 
    <title>Some video</title> 
    <stream>rtsp://example.com/media/1.3gp</stream> 
</media> 

2) 매체/스트림 자체에 대한 액세스
이것은 더 문제가되는 비트입니다. 질문에 이미 하나의 옵션을 지적 했으므로 RESTful API를 통해 개별적으로 프레임에 액세스 할 수 있습니다. 이 방법이 효과가있을지라도 나는 그것이 실행 가능한 선택이 아니라는 점에 동의합니다.

나는 사이하는 선택의 여지가 있다고 생각한다

1. 전문 스트리밍 프로토콜을 통해 전용 서비스로 스트리밍 위임 (예 : RTSP) HTTP에 사용할 수있는 옵션을 활용

전용 스트리밍 서비스 (및/또는 하드웨어)이 필요하지만 전자는 더 효율적인 선택이라고 생각합니다. RESTful로 간주되는 것의 가장자리에 조금있을 수도 있지만 API가 모든 측면에서 RESTful이며 전용 스트리밍 서비스가 균일 인터페이스 (GET/POST/PUT/DELETE)를 따르지 않더라도 Google API 않습니다. 우리 API는 GET/POST/PUT/DELETE를 통해 리소스와 메타 데이터를 적절하게 제어 할 수있게하며 스트리밍 서비스에 대한 링크를 제공합니다 (따라서 REST의 연결성 측면을 준수합니다).

후자의 옵션 - HTTP을 통한 스트리밍은 위와 같이 효율적이지 않을 수 있지만 확실히 가능합니다. 엄밀히 말하자면, HTTP를 통해 이진 컨텐트의 어떤 형태로든 액세스하는 것을 허용하는 것만 큼 다르지 않습니다. 이 경우 우리의 API는 HTTP를 통해 액세스 할 바이너리 자원에 대한 링크를 제공 할 것, 또한 자원의 크기에 대한 정보를 조언 :

GET /media/1 

<?xml version="1.0" encoding="UTF-8" ?> 
<media uri="/media/1"> 
    <id>1</id> 
    <title>Some video</title> 
    <bytes>1048576</bytes> 
    <stream>/media/1.3gp</stream> 
</media> 

클라이언트는 GET /media/1.3gp를 사용하여 HTTP를 통해 리소스에 액세스 할 수 있습니다. 하나의 옵션은 클라이언트가 전체 리소스 (HTTP progressive download)를 다운로드하는 것입니다. 더 깨끗한 대안은 클라이언트가 HTTP Range headers을 사용하여 청크로 리소스에 액세스하는 것입니다. 1메가바이트 큰 파일의 두 번째 2백56킬로바이트 청크를 가져 오는 경우, 클라이언트 요청은 다음과 같을 것이다 : 자원의 부분적인 표현 다음에

GET /media/1.3gp 
... 
Range: bytes=131072-262143 
... 

범위는 다음 Content-Range header로 응답 할 것이다 지원하는 서버, :

HTTP/1.1 206 Partial content 
... 
Content-Range: bytes 131072-262143/1048576 
Content-Length: 1048576 
... 

Google API는 이미 클라이언트에게 파일의 실제 크기 (바이트) (1MB)를 알려줍니다. 클라이언트가 리소스의 크기를 알지 못하는 경우 먼저 크기를 확인하기 위해 HEAD /media/1.3gp을 호출해야합니다. 그렇지 않으면 416 Requested Range Not Satisfiable으로 서버 응답을받을 위험이 있습니다.