RESTFul管理巨大的資源，陳述和預測

我需要管理非常大的元素在我的RESTFul設計。我試圖以一種我可以吐出這些元素的方式應用「分割等等」方法，但是它導致了最小的元素，但它們仍然太大。RESTFul管理巨大的資源，陳述和預測

所以有兩個選擇，我可以使用，我想問你們這個想法。

關於「表示法」我可以使用不同的URI來管理它們。例如， /API/resourcex /對資源的最小表示X /API/resourcex_big /對資源X /API/resourcex_full /整個資源X

ELSE

的一大表現我可以用分層方式 /API/resourcex/ /API/resourcex /大 /API/resourcex /全

你認爲什麼是語義correnct？我選擇第一個，因爲我想保留資源的「子元素」的層次關係。

例如，我想用例如。/api/resourcex /對於資源x的列表，然後使用resourcex_big/{id}作爲從resource_x列表鏈接的表示作爲目標詳細信息。然後將resource_full用於其他類型的表示，例如全部細節的請求。

說有一點2是：我需要創建一個聰明的東西，以做一個動態投影的資源。這是因爲代表對於客戶來說太大，我需要選擇一些數據點來顯示最適合其需求的數據點。這裏我的問題是：哪個是投影請求的最佳URI格式？再一次，更好的是一種分層的方式（如在下面的例子中）或查詢字符串？

-- Creation of a projection 
**> POST /projection/ HTTP/1.1** 
{ resource:」resourcex」, 「name」: true, 「price」: true } 
**< HTTP/1.1 201 Created** 
Location: http://www.sample.org/api/projection/123 (absolute url) 
-- Request of a projection 
**> GET /resourcex/999/projection/123 HTTP/1.1**

來源

2014-01-29 franco

我個人更喜歡查詢字符串，因爲它是相同的資源，對吧？

在文檔中寫入，該資源可通過網址http://example.com/resource/<id>訪問，它有一個可選參數size，默認情況下它設置爲「預覽」。

http://example.com/resource/X # implies the query-parameter "size=preview" 

http://example.com/resource/X?size=preview 
http://example.com/resource/X?size=original

其他的東西並不在我眼中，因爲它的意圖是使用一個URI訪問一個資源。在這種情況下，您正在訪問相同的資源，但要求取回它的修改版本，在這種情況下，它的大小不同。這是我個人將作爲查詢參數放入的內容。

來源

2014-01-29 08:24:47 SimonSimCity

據我所知，我們可以在相同的資源的別名有不同的URI點。據我所知，我認爲我們可以使用資源的表示，這些資源是我們想要公開的資源的抽象。也許我錯了，但這些都是那些URI的設計（約單個資源的不同表示的第一部分）下的基本思路。感謝您的回答:) – franco

這就是說，你還可以看到一個預覽圖像作爲原始資源的修改版本，但在這種情況下，我將提供原始資源調用時'http://example.com/resource/'。這也將是該位置的頭中返回的一個，即便如此，你可以在修改後的版本使用不同的URI訪問資源。但我認爲這取決於你如何看待它:) – SimonSimCity

我會建議將您的資源分成多個子資源。

如果有數據的巨大量而您只需要其中的一部分，你可以設計你的API只取放入系統是這樣的：

GET /resources/999/name 
GET /resources/999/price

這2個查詢可能會比輕得多充分代表GET /resources/999。

之一大優勢的這是，你可以重用這些URI進行其他操作，如POST /resources/999/price改價格，而不是使用PATCH /resources/999。它也可以簡化您的緩存清除策略，這樣當你改變價格，你只無效/resources/999和/resources/999/price同時保持所有/resources/999/*條目保持不變。

在這種情況下你預測是提前知道，您可以創建特定的媒體類型，例如：

GET /resources/999 
Accept: application/vnd.yourcompany.resourcetype+json 
# Receiving full representation of /resources/999 

GET /resources/999 
Accept: application/vnd.yourcompany.resourcetype.light+json 
# Receiving light representation of /resources/999 

GET /resources/999 
Accept: application/vnd.yourcompany.resourcetype.name_price+json 
# Receiving "name" and "price" from /resources/999

這種方法的好處是，你可以減少請求數量獲取許多屬性而不用全部獲取它們。

您也有可能創建一個API來創建可重複使用的媒體類型（「預測」），但由於媒體類型通常定義了服務器和客戶端之間的一些合同，這可能是一個冒險的做法。

來源

2016-06-21 09:51:26

RESTFul管理巨大的資源，陳述和預測

回答

相關問題