提供批量請求的ID

我正在設計一個API，我希望允許客戶端能夠一次創建多個資源。客戶可以發佈包含多個項目的訂單。提供批量請求的ID

一種方法是允許客戶在訂單級別和每個項目級別提供唯一的ID，並且我存儲那些（以及我們的內部項目），但是這將允許客戶基於它的ID。請求示例：

{ 
    order_ref: 'XXX', 
    items: [ 
    { item_ref: 'xx', quantity: 5 }, 
    { item_ref: 'yy', quantity: 5 }, 
    ] 
}

另一種方法是返回一個ID爲順序以及每個項目的，但似乎沒有escalable作爲一個訂單可以有很多的項目，這樣的請求可能甚至超時。這也意味着退貨需要按順序進行，以便他們能夠將返回的ID與他們所要求的ID進行匹配。

應該採取什麼樣的方法？

來源

2016-02-27 Hommer Smith

如果你採取你的第一種方法，客戶端必須創建ids。有時候這沒問題，但通常對他們來說很煩人。除非id是不會改變的事物的內在組成部分，否則他們將不得不提出自己的隨機id並將其存儲在自己的本地數據庫中。如果你的客戶希望能夠做到這一點，這是正確的做法。您應該通過資源類型在其生成的id中實施唯一性，並將其用於數據庫中。

否則，第二種方法是可取的，因爲惱人的客戶是不利的業務。是的，如果他們添加了一千個新項目，它的規模會很小，但響應不會比請求大得多，因爲您只是在響應中添加了「id」屬性。

來源

2016-02-29 19:44:20

我主要關注的第二種方法是，當從請求創建所有資源時，它可能會超時（因爲可能會有很多資源）。你通常如何處理這種情況？你有限制嗎？如果你有任何資源可以在這方面進行教育，我將不勝感激。 –

使POST異步。創建某種狀態端點，例如/ pendingOrders。立即回覆POST，並將位置標頭設置爲/ pendingOrders/{id}，並在正文中包含有關請求何時完成的猜測。客戶可以通過GET/pendingOrders/{id}來獲得訂單生成的狀態。最終，訂單將完成，並且GET響應可以包含系統中新訂單的URI。 –

但如果這個「訂單」正在創造多種資源，他們怎麼知道哪一個是哪個？ –

提供批量請求的ID

回答

相關問題