2013-08-01 57 views
1

出於某種原因,我的應用程序需要有一個流動像一個API:RESTful方式預先分配的ID

  1. 客戶端調用服務器以獲取ID爲新資源。
  2. 然後用戶花了一段時間填寫資源的表單。
  3. 然後用戶點擊保存(或不...),而當他做的客戶端通過寫/myresource/{id}

什麼是設計這個RESTful方式保存?

第一個電話應該怎麼樣?在服務器端,這是生成一個ID並返回它的問題。它有副作用(增量序列,因此「保留空間」),但它沒有明確地創建資源。

如果我理解正確,第三個調用應該是PUT,因爲它使用已知的URI創建了一些東西。

回答

0

我很想看到這個問題的其他答案,因爲我想有很多方法可以做到這一點。

如果可能,我會讓你的數據庫中的自動遞增ID作爲代理鍵,並指定另一個字段爲業務標識。它可能類似於產品代碼或GUID

考慮到這一點,客戶現在可以創建自己的ID,它根本不需要第1步。他們會對一個網址(例如/myresource/MLN5001/myresource/3F2504E0-4F89-11D3-9A0C-0305E82C3301)執行PUT以創建資源。如果該ID已在使用中,則返回409 Conflict與響應正文中的衝突。否則返回201 Created並在響應正文和位置標頭中包含資源的URI。你可以做到這一點

+0

的事情是,往往不是有無數的資源並沒有爲用戶控制他們的數字的方式。如果您每天創建100個訂單(每年36,500個訂單),則不能指望併發用戶手動輸入標識符或創建唯一值。 –

+0

他們已經在訂單中輸入,選擇其中一個填寫的字段並將其用作您的業務標識符。或者,您可以生成一個GUID客戶端(碰撞風險可以忽略不計)。 – Mike

1

一種方法是:

  • 客戶POST空的身體/myresource/
  • 與一個Location響應頭設置爲/myresource/newresourceid(狀態代碼302 (Found)服務器應答指示ID/URI是應該用於創建資源)
  • 客戶端PUT是用戶完成填寫表單後的新資源到/myresource/newresourceid

似乎足夠RESTful。 ;)

+0

它感覺骯髒,似乎並沒有工作。當服務器發送302時,瀏覽器總是自動遵循重定向。它應該,因爲這就是302的用途。 –

+0

好點... Ajax請求總是遵循3XX,所以你最終會得到404s。 –

+0

另一個想法(大聲思考):如何將新ID公開爲收集端點上的自定義標頭: - 客戶端在/ myresource /?上執行HEAD(或POST?)generateId = true - 服務器響應空主體和標題「X-New-Id:12345」(或帶有新資源的URL的位置標題)。 自定義標頭並不是很優雅,但這不是一個非常標準的REST操作。 –

0

我會去與

GET /myresource/new-id 
POST /myresource/{id} 

你的演練是對動詞很清楚:

  1. 「來獲得[一] ID爲新資源」

您可以將new-id重命名爲任何您認爲最清楚的內容。如果你有多個資源,你需要爲做到這一點,它可能會是更好的發電機拆分到它自己的資源,如

GET /id-generator/myresource 
GET /id-generator/my-other-resource 

如果有多個的情況下,用戶會很快了解他們需要命中id發電機來獲得他們的ID。如果只有一種情況,那麼他們很少使用它很煩人。

我猜你也可以做

GET /myresource-id-generator/next 

看起來更清晰一點,但當時如果你需要生成另一個ID,你必須做出其他資源來做到這一點。

+0

GET感覺不對,因爲它會隨着時間而改變,它有副作用,它不是冪等的... –

0

ID分配是非冪等的 - 分配操作的兩次調用將獲得不同 ID - 因此應始終爲POST。從那時起,資源應該在概念上存在。然而,我現在要做的就是用合理的默認值填充它(不管是涉及做POST還是PUT對整體設計的RESTful性而言都不重要),因此用戶可以花時間改變事物他們希望看起來像他們想要他們。

然後問題就變成了是否應該有某種「釋放這個;我完成了改變它「最後的操作。嚴格的RESTfulness說不應該,就好像你知道資源標識符(URL)那麼你可以談論它。另一方面,這並不意味着託管服務器必須告知其他人關於該資源,直到創建用戶滿意爲止;一般的HATEOAS原則沒有提到什麼時候別人可以發現資源的存在或知道該名稱是否讓你閱讀該事物,但是完全合理的做法是拒絕第三方資源的存在,直到資源所有者開啓「make this公衆「旗幟。

相關問題