什麼是正確的方式來處理HTTP緩存OData查詢？

Question

我想使用OData並從HTTP緩存中獲得一些好處。我已經解決了規則「一個實體有一個URI」。有許多方法如何執行查詢的一個實體，可以說產品與SKU = 123（這是PK）：

/MyService.svc/Product(123) 

或

/MyService.svc/Product?$filter=sku eq 123 

甚至

/MyService.svc/Product(123)?$filter=sku eq 123 

的最不起眼的方式如何查詢該產品是通過標題：

/MyService.svc/Product?$filter=title eq 'Some handy product' 

（讓我們期待這個查詢只返回一個實體 - 產品123）

我的問題是：什麼是最OData方式如何響應這種查詢？

經過一番研究，我最後的意見是：

• 讓產物（123）工作的是
• 在$過濾器的情況下= SKU EQ 123/ID EQ 123 HTTP 302和Location頭響應指向產品（123）。
• 在產品（123）的情況下？$ filter = sku eq 123以400（壞請求）響應，因爲它很愚蠢。或者，也許用302重定向到產品（123）..

但是如何處理最後一種情況？

Answer 1

產品（123） - >您應該返回單個實體在響應有效載荷

產品（123）$濾芯的SKU EQ 123？ - >這並不是真正意義 - 過濾器應該申請到實體的集合，產品（123）標識單個實體（總是）。由於行爲或早期服務器堆棧，現在許多OData服務忽略此操作，但由於查詢選項不適用，400可以接受。

Product？$ filter = sku eq 123 - > Product標識一個實體集合，因此應該返回一個實體集合（AKA提要）。即使您的特定查詢碰巧識別了單個實體，但其中包含單個實體的供稿也是REQUIRED響應。

Product？$ filter = title eq'一些便利的產品' - >就預期響應而言，這與sku eq 123相同。即使它可能識別單個資源，但這並不會改變實體集必須仍包含供稿作爲響應的事實。

你說你想保持一個實體有一個URL的規則。在OData中，一個URL標識一個實體，但多個URL可以爲您提供相同的信息。所以，我認爲你沒問題。標識資源的一個URL稱爲規範URL。產品（123）是規範URL。例如，在JSON有效載荷中，odata.id會給出實體的規範URL。

那麼SEEM引用同一個實體的其他查詢呢？在您的有效過濾器示例中（第3和第4個示例），您的路徑按照上面所述標識了COLLECTION。收集恰好只包含一個實體的事實是無關緊要的。識別資源的路徑仍然是Product（123）。其他網址可以提供有關該實體的信息，而不用「識別」該信息。所以我不認爲你已經破壞了你的言論。

要回答你的問題的3xx部分：你總是可以自由地對某種請求做出迴應 - 這是HTTP的一部分，而OData不會改變這種情況。但是，重定向到與原始請求形狀不一樣的東西將是一種糟糕的服務器行爲。例如，Product（123）？$ filter = whatever標識產品實體集合。重定向到產品（123）在我看來是一個壞主意，因爲它確定了一個實體。你會寫出的迴應看起來不一樣！如果任何現有的OData客戶端可以處理該問題，我會感到驚訝，我也不希望新的客戶端能夠處理它。

這對HTTP緩存有什麼意義？坦率地說，至少在這種情況下，我認爲你不應該做任何特別的事情。