ทรัพยากรการสตรีมจะเหมาะสมกับกระบวนทัศน์ RESTful ได้อย่างไร

ด้วยบริการ RESTful คุณสามารถสร้างอ่านอัปเดตและลบทรัพยากรได้ ทั้งหมดนี้ทำงานได้ดีเมื่อคุณจัดการกับบางอย่างเช่นสินทรัพย์ฐานข้อมูล แต่สิ่งนี้จะแปลเป็นข้อมูลสตรีมมิ่งได้อย่างไร (หรือเปล่า?) ตัวอย่างเช่นในกรณีของวิดีโอดูเหมือนเป็นเรื่องไร้สาระที่จะถือว่าแต่ละเฟรมเป็นทรัพยากรที่ฉันควรสืบค้นทีละรายการ แต่ฉันจะตั้งค่าการเชื่อมต่อซ็อกเก็ตและสตรีมเฟรมต่างๆ แต่สิ่งนี้ทำลายกระบวนทัศน์ RESTful หรือไม่? จะเป็นอย่างไรหากฉันต้องการย้อนกลับหรือกรอสตรีมไปข้างหน้า สิ่งนี้เป็นไปได้ภายในกระบวนทัศน์ RESTful หรือไม่? ดังนั้น: ทรัพยากรการสตรีมจะเหมาะสมกับกระบวนทัศน์ RESTful ได้อย่างไร

สำหรับการนำไปใช้งานฉันกำลังเตรียมพร้อมที่จะสร้างบริการข้อมูลสตรีมมิ่งดังกล่าวและต้องการให้แน่ใจว่าฉันกำลังทำ "วิธีที่ดีที่สุด" ฉันแน่ใจว่าปัญหานี้ได้รับการแก้ไขมาก่อน ใครช่วยชี้ทางให้ฉันดูเนื้อหาดีๆ

ฉันไม่สามารถหาข้อมูลเกี่ยวกับการสตรีมแบบ RESTful ได้อย่างแท้จริง- ดูเหมือนว่าผลลัพธ์ส่วนใหญ่จะเกี่ยวกับการมอบหมายสตรีมมิงไปยังบริการอื่น (ซึ่งไม่ใช่วิธีแก้ปัญหาที่ไม่ดี) ดังนั้นฉันจะพยายามอย่างเต็มที่เพื่อจัดการกับมันเอง - โปรดทราบว่าการสตรีมไม่ใช่โดเมนของฉัน แต่ฉันจะพยายามเพิ่ม 2 เซ็นต์ของฉัน

ในแง่มุมของการสตรีมฉันคิดว่าเราจำเป็นต้องแยกปัญหาออกเป็นสองส่วนอย่างอิสระ:

1. เข้าถึงทรัพยากรสื่อ (ข้อมูลเมตา)
2. เข้าถึงสื่อ / สตรีมเอง (ข้อมูลไบนารี)

1. ) การเข้าถึงแหล่งข้อมูลสื่อ
สิ่งนี้ค่อนข้างตรงไปตรงมาและสามารถจัดการได้อย่างสะอาดหมดจดและปลอดภัย ตัวอย่างเช่นสมมติว่าเราจะมี API ที่ใช้ XML ซึ่งช่วยให้เราสามารถเข้าถึงรายการสตรีม:

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 ในทุกด้านและแม้ว่าบริการสตรีมมิงเฉพาะจะไม่เป็นไปตามอินเทอร์เฟซที่เหมือนกัน (GET / POST / PUT / DELETE) 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>

ไคลเอนต์สามารถเข้าถึงทรัพยากรผ่าน HTTP โดยใช้GET /media/1.3gp. ทางเลือกหนึ่งคือสำหรับลูกค้าในการดาวน์โหลดทรัพยากรทั้งหมด - HTTP ดาวน์โหลดก้าวหน้า ทางเลือกที่สะอาดจะเป็นสำหรับลูกค้าในการเข้าถึงทรัพยากรในชิ้นโดยใช้ HTTP ส่วนหัวของช่วง สำหรับการดึงไฟล์ 256KB ที่สองของไฟล์ที่มีขนาดใหญ่ 1MB คำขอของไคลเอ็นต์จะมีลักษณะดังนี้:

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

เซิร์ฟเวอร์ที่รองรับช่วงจะตอบสนองด้วยส่วนหัวของช่วงเนื้อหาตามด้วยการแสดงทรัพยากรบางส่วน:

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

โปรดทราบว่า API ของเราได้บอกลูกค้าแล้วว่าขนาดไฟล์เป็นไบต์ (1MB) ในกรณีที่ลูกค้าจะไม่ทราบขนาดของทรัพยากรที่มันเป็นครั้งแรกควรจะเรียกเพื่อตรวจสอบขนาดมิฉะนั้นก็เสี่ยงต่อการตอบสนองกับเซิร์ฟเวอร์HEAD /media/1.3gp416 Requested Range Not Satisfiable