在REST服務中查詢和表單參數的混合？

我們有一個REST API，對於某些操作，我們提供異步請求選項。對於異步請求，服務將立即返回一個可用於查詢完成的令牌，而對於同步請求，只有操作完成時纔會返回響應。在REST服務中查詢和表單參數的混合？

目前的設計，這看起來是這樣的：

網址：PUT /api/orders/1234?async=true

請求正文：customerName=My Company&city=Dallas

直觀地看，它似乎是錯誤的混合查詢和形式PARAMS這樣，但是查詢param（異步）爲服務調用提供選項，而不是資源的屬性。這是我們沒有將其包含在請求主體中的主要原因。

這種方法看起來好像是一個很好的設計，還是有更好的「REST-y」方式來完成相同的工作？

來源

2013-08-19 WayneC

Prefer標頭旨在完成您正在嘗試執行的操作。請參閱spec。

來源

2013-08-19 20:40:41

來自草稿：「到期日：2013年7月11日」。所以這個頭文件不是HTTP的一部分。 – 2013-08-20 06:38:44

@Tichodroma該規範已通過IETF正式程序批准並正在進行中。 http://datatracker.ietf.org/doc/draft-snell-http-prefer/history/由於各種互操作規範，網絡運作良好。媒體類型不是「HTTP的一部分」。許多HTTP方法不是由HTTP規範定義的（例如PATCH）。響應代碼也一樣。這就是它應該如何工作。 –

這樣

POST /api/orders/1234?async=true

的網址是不是RESTful的。爲什麼POST？這看起來像RPC over HTTP。

您的資源是什麼？如果涉及一些計算，則將計算建模爲資源。 POST到一組計算器來創建一個新計算器。接收計算結果的Location標題。

POST /api/orders 

custoerName=My Company 
city=Dallas

這可能會返回類似這樣的回覆：

201 Created 
Location: /api/orders/1234

然後，客戶機可以GET結果：

GET /api/orders/1234

而且服務器會迴應：

200 OK 

Some result body.

如何使這個asynchronouse？

你寫：

但是查詢參數（異步）正在提供的選項服務調用，而不是資源

這是完全錯誤的屬性。全部即在URI中用於識別的資源。 REST不是用參數調用方法。

我推薦使用總是在將計算/交易/購物車作爲資源進行建模時，使用上述兩步法。創建它，檢索它。

來源

2013-08-19 19:03:16

你是對的，這應該是我想描述的場景中的「PUT」（更新）。我將編輯原始問題進行說明。然而，問題的要點是如何讓客戶指定他們是否要等待操作完成。 – WayneC

客戶等待或他不等。這完全取決於他。在這兩種情況下，服務器應始終以響應描述資源的當前服務器狀態來響應「GET」請求。 – 2013-08-19 19:38:57

在REST服務中查詢和表單參數的混合？

回答

相關問題