스트리밍 리소스가 RESTful 패러다임에 어떻게 부합합니까?

RESTful 서비스를 사용하면 리소스를 생성, 읽기, 업데이트 및 삭제할 수 있습니다. 이 모든 것은 데이터베이스 자산과 같은 것을 다룰 때 잘 작동하지만 이것이 스트리밍 데이터로 어떻게 변환 될까요? 예를 들어 비디오의 경우 각 프레임을 한 번에 하나씩 쿼리해야하는 리소스로 취급하는 것은 어리석은 것 같습니다. 오히려 소켓 연결을 설정하고 일련의 프레임을 스트리밍합니다. 그러나 이것이 RESTful 패러다임을 깨뜨릴까요? 스트림을 되감거나 빨리 감 으려면 어떻게해야합니까? RESTful 패러다임 내에서 가능합니까? 그렇다면 스트리밍 리소스는 RESTful 패러다임에 어떻게 부합할까요?

구현 문제로 이러한 스트리밍 데이터 서비스를 만들 준비를하고 있으며 "최선의 방법"을 사용하고 있는지 확인하고 싶습니다. 이 문제는 이전에 해결되었다고 확신합니다. 누군가 저에게 좋은 자료를 알려줄 수 있습니까?

나는 진정한 RESTful 스트리밍 에 대한 자료를 찾지 못했습니다. 결과는 대부분 다른 서비스에 스트리밍을 위임하는 것으로 보입니다 (나쁜 해결책은 아닙니다). 그래서 저는 최선을 다해 직접 해결하겠습니다. 스트리밍은 제 도메인이 아니지만 2 센트를 추가하려고합니다.

스트리밍 측면에서 문제를 두 개의 독립적 인 부분으로 분리해야한다고 생각합니다.

1. 미디어 리소스 (메타 데이터)에 대한 액세스
2. 매체 / 스트림 자체에 대한 액세스 (이진 데이터)

1.) 미디어 리소스에 대한 액세스
이것은 매우 간단하며 깔끔하고 RESTful 방식으로 처리 할 수 ​​있습니다. 예를 들어, 스트림 목록에 액세스 할 수있는 XML 기반 API가 있다고 가정 해 보겠습니다.

GET /media/

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

... 또한 개별 스트림 :

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)을 통해 전용 서비스에 스트리밍 위임
2. HTTP에서 사용 가능한 옵션 활용

전용 스트리밍 서비스 (및 / 또는 하드웨어)가 필요하지만 전자가 더 효율적인 선택이라고 생각합니다 . RESTful로 간주되는 것의 가장자리에있을 수 있지만 API는 모든 측면에서 RESTful이며 전용 스트리밍 서비스가 API 인 균일 인터페이스 (GET / POST / PUT / DELETE)를 준수하지 않더라도 않습니다. 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>

클라이언트는를 사용하여 HTTP를 통해 리소스에 액세스 할 수 있습니다 GET /media/1.3gp. 한 가지 옵션은 클라이언트가 전체 리소스 ( HTTP 점진적 다운로드)를 다운로드하는 것 입니다. 더 깨끗한 대안은 클라이언트가 HTTP 범위 헤더 를 사용하여 청크 단위로 리소스에 액세스하는 것 입니다. 크기가 1MB 인 파일의 두 번째 256KB 청크를 가져 오는 경우 클라이언트 요청은 다음과 같습니다.

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

범위를 지원하는 서버는 Content-Range 헤더 로 응답 하고 리소스의 부분 표현이 이어집니다.

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

API는 이미 클라이언트에게 파일의 정확한 크기 (1MB)를 알려줍니다. 클라이언트가 리소스의 크기를 모를 경우 먼저 HEAD /media/1.3gp크기를 결정하기 위해 호출해야 합니다. 그렇지 않으면 416 Requested Range Not Satisfiable.