可以從REST接口返回application/octet-stream嗎？

我是否通過返回應用程序/八位字節流來響應REST聖經中的任何法律？ REST端點接收5個圖像URL。可以從REST接口返回application/octet-stream嗎？

{ "image1": "http://ww.o.com/1.gif", 
    "image2": "http://www.foo.be/2.gif" }

它會下載並返回它們作爲application/octet-stream。

CLARIFICATION：調用此REST接口的客戶端是移動應用程序。每增加一次網絡連接都會使電池壽命縮短几毫安。我被迫使用REST，因爲它是一個公司標準。如果沒有，我會做我自己的二進制協議。

來源

2009-10-20 Jacques René Mesrine

它不是那麼好，因爲客戶端將不知道如何處理這樣的二進制數據盡除地方存放這些字節或進一步向他們發送到其他進程的（如果這是你需要與你的數據做的，那麼很好）。

你可以看看multipart內容類型。國際海事組織，包含幾個image/gif部分的多部分信息將是一個更好的選擇。

來源

2009-10-20 02:23:25

如前所述，問題不是有效負載，而是內容類型。理想情況下，內容類型儘可能好地描述數據。 Multipart在這裏更合適。它還允許您混合圖像（比如說，合併PNG和JPG）。而且這個成本對於新的元數據而言是最小的開銷。 – 2009-10-20 03:46:51

爲什麼不能有五個單獨的REST調用？

似乎更清潔，並在邏輯上分得更多。它還將並行運行下載，每次2個或更多，具體取決於您使用的瀏覽器。

來源

2009-10-20 02:24:45

也許真的有'n'個URL，並且使用HTTP req/resp爲每個單個圖像迭代它們可能會很昂貴。如果每個請求只有幾個鏈接，通過提供單個圖像可以使事情變得更加簡單。 – 2009-10-20 02:27:54

除n值很大的情況外，將它們打包在一起並不是很RESTful。如果n非常大，也許另一種策略會更有意義。 – 2009-10-20 02:38:15

客戶端不是瀏覽器，而是原生移動應用程序。 – 2009-10-20 03:37:05

從這個聲音，這聽起來更像一個RPC調用。具體來說，「這裏是一個URL列表，給我回檔案」。

即製造方法沒有特別的RESTful，如REST不是基於RPC系統。

你需要做的是把檔案爲reources和方法來創建，然後爲他們服務了。

例如，你可以：

POST /archives 
Content-Type: application/json 

{ "image1": "http://ww.o.com/1.gif", 
    "image2": "http://www.foo.be/2.gif" }

結果，你會得到

HTTP/1.1 201 Created 
Location: http://example.com/archives/1234 
Content-Type: application/json

然後，你可以做一個請求http://example.com：

GET /archives/1234 
Accept: multipart/mixed

在這裏，你將會在一個請求中得到實際的存檔（就像你想的那樣），只是它是一個多部分格式化的結果。（多/ X-ZIP將工作太，這是一個zip文件）

如果你做的事：

GET /archives/1234 
Accept: application/json

你還是會回到你送原（所以你可以，也許是JSON，編輯和更新存檔，你可能不想支持發送二進制圖像）。

要改變它，你只會回傳的更新：

PUT /archives/1234 
Content-Type: application/json 

{ "image1": "http://ww.o.com/1.gif", 
    "image2": "http://www.foo.be/2.gif", 
    "image3": "http://www.foo2.foo/4.gif" }

的資源/存檔/ 1234，這是它的名字。

它在這種情況下兩種表示：JSON的版本，實際的，二進制歸檔。您的服務使用Accept標頭中指定的內容類型區分兩者。該標題是客戶告訴你它想要什麼。

當你與歸檔完成後，只需將其刪除

DELETE /archives/1234

或者你可以讓服務器到期後的某個時刻的資源。

來源

2009-10-20 04:04:48

難道你不會把'PUT'和'POST'混淆嗎？ 'PUT'通常用於更新像'/ archives/1234'這樣的資源，'POST'用於在你的例子中創建新的東西，例如'POST/archives'。 – 2009-10-20 11:02:39

你說得對，我已經換掉了 – 2009-10-22 03:00:51

他們被稱爲REST原則而不是法律，但不是你不「打破」他們，國際海事組織。 REST是關於可通過URL尋址的資源，以及（在適當的情況下）以多種格式可用的資源。它沒有說明格式應該是什麼。有一個REST意思是in this article的簡單描述。

不過，正如@Andrey所說，發明多個數據對象比發明自己的adhoc格式更好。 Multipart mimeType /格式是一種替代方法，另一種方法是將打包的對象作爲tar，zip或類似的歸檔文件格式發送。

IMO。使用「application/octet-stream」的真正問題在於它沒有告訴任何有關數據如何實際格式化的任何信息。而是你的客戶已經「知道」它是如何格式化的，並相應地解釋它。發明自己格式的問題是互操作性，並且（可能）必須設計，實現和維護庫以支持它，可能可能會結束。

來源

2009-10-20 04:05:30

可以從REST接口返回application/octet-stream嗎？

回答

相關問題