REST風格的帖子，你是否將單個對象設置爲單數或複數Uri？

這些URI中哪一個更適合接收POST（添加產品）？是否有最佳實踐可用或僅僅是個人偏好？REST風格的帖子，你是否將單個對象設置爲單數或複數Uri？

/產品/（單數）

或

/產品/（複數）

目前我們使用/products/?query=blah用於搜索和/product/{productId}/爲GET的把一個單一產品的& DELETE操作。

2009-11-06 Arron S

讓我覺得在編程藏品 - 項目[4]或項目[4]。 – 2013-03-15 20:28:24

要做的RESTful事情將是對集合和單個項目使用*相同的*前綴。所以你可以POST或者PUT到你可以從中獲取的同一端點。如果您在服務器上生成ID，則約定將POST到集合中。如果在客戶端生成ID，則約定將POST到'/ endpoint/{new_id}'。 – 2017-06-26 19:18:23

由於POST是一個「追加」操作，因此您可能會將更新爲/products，因爲您會將新產品附加到現有產品列表中。

只要你在你的API中標準化了某些東西，我認爲這已經足夠了。

因爲REST API應該是超文本驅動的，所以URI無論如何都是相對無關緊要的。客戶應該從返回的文檔中提取URI並在隨後的請求中使用這些URI;通常應用程序和人們不需要猜測或可視化地解釋URI，因爲應用程序將明確地指示客戶端可用的資源和URI。

來源

2009-11-06 20:46:55

我會進一步說，使用複數形式肯定比單數更自然。 – 2009-11-06 21:26:10

如果你想創建一個可讀的URL段落，單數有時聽起來更自然（對於讀者），例如「/ product/15」，直接閱讀是「產品15」，所以你知道你正在處理一個獨特的產品。但是，你只剩下「如何處理所有產品的列表」，把它放在/產品（這聽起來很奇怪）或/產品（必須支持代碼中相同類型資源的兩個URI ）。但在任何情況下，可讀的URI段落通常都不是REST設計應用程序的目標，因爲它通常不適合人類使用。 – 2009-11-06 21:31:20

重新閱讀我的評論我意識到我的意圖不是很清楚。我傾向於使用複數來使用POST來追加，但如果資源是單個實體，則使用複數來表示GET和PUT。正如我在過去所說的REST uris與OO設計中類和方法的命名一樣重要。即使用好名字並不重要，但它確實有幫助。 – 2009-11-07 00:43:08

您發佈或獲取一件事：一個產品。

有時你GET沒有特定的產品（或與查詢條件）。但你仍然用單數來說。

你很少工作複數形式的名字。如果您有一個集合（一個產品目錄），它是一個目錄。

來源

2009-11-06 20:43:17

我對RESTful API所見到的大多數建議都是相反的。由於根是集合（複數），因此具有/產品和/產品/ {id}會更有意義，並且具有標識符的那個是該集合中的一個項目（從複數=單數中選擇）。產品可能被認爲是一個目錄，但如果它是電影或評論呢？ – 2009-11-06 20:51:24

儘管真的 - 即使StackOverflow在其URL中使用複數集合 - 我不同意。 Singular更有意義，因爲URI標識（單數）資源 - 特別是POST。 – 2009-11-06 21:17:41

URI確實標識資源。有時候資源是一系列事物。我沒有理由把自己限制在單數名詞中。 – 2009-11-06 21:29:26

通常情況下，如果您事先不知道資源的標識符，則使用POST創建資源，而當您執行時則使用PUT。所以你會POST到/ products，或者PUT到/ products/{new-id}。

使用這兩種方法，您將返回201 Created，並使用POST另外返回包含新創建資源的URL（假定它已成功創建）的Location標頭。

來源

2009-11-06 20:46:56

另外一個提到'位置'標題，這是經常被遺忘的。 – 2017-06-26 19:25:04

-2

您可以對它們使用相同的url並使用MessageContext來確定Web服務的調用者想要執行的操作類型。沒有語言被指定，但在Java中，你可以做這樣的事情。

WebServiceContext ws_ctx; 
MessageContext ctx = ws_ctx.getMessageContext(); 
String action = (String)ctx.get(MessageContext.HTTP_REQUEST_METHOD); 
if(action.equals("GET") 
    // do something 
else if(action.equals("POST") 
    // do something

這樣您就可以檢查發送到Web服務的請求的類型，並根據請求方法執行相應的操作。

來源

2009-11-06 20:58:19 ChadNC

但是他應該使用哪個URI，單數還是複數？ – 2009-11-06 21:00:13

無論他想要什麼，都可以工作。根據請求方法他可以使用複數形式或單數形式，因爲執行的操作將僅取決於請求最佳方法。因此/ product？query = blah可以通過使用請求方法處理與/ products？query = blah相同的請求。我希望這是一個漫長的一天，我的大腦已經很累了。 – ChadNC 2009-11-06 21:41:01

不回答這個問題：單數還是複數。許多框架已經支持基於HTTP請求方法的路由（不需要手動編碼）。 – 2011-04-26 23:02:56

我只會發布到單數/product。混淆這兩個網址很容易混淆或者犯錯誤。

來源

2009-11-10 18:58:39

Aaack。張貼複數，而不是單數。複數給出了一個合理的指數，單數不合。 – MikeSchinkel 2010-08-15 19:43:26

在REST風格的設計中，圍繞創建新資源存在一些模式。您選擇的模式在很大程度上取決於誰負責爲新創建的資源選擇URL。

如果客戶端負責選擇URL，那麼客戶端應該放入資源的URL。相反，如果服務器負責資源的URL，則客戶端應該POST到「工廠」資源。通常，工廠資源是正在創建的資源的父資源，通常是多元化的集合。

所以，你的情況我會建議使用/products

來源

2009-11-10 19:03:54

正如許多說，你也許可以選擇你喜歡，只要你是一致的任何風格，但是我想指出，雙方一些參數;我個人對奇異

偏向於多個資源名稱：

簡單的URL方案的你也知道資源的名稱是始終在多個
許多人認爲這個約定類似於如何數據庫表處理，並認爲這是一個優勢
似乎更廣泛採用

贊成單一的資源名稱（這並不排除複數多個資源工作時）

的URL方案較爲複雜，但你獲得更多的表現力
你總是知道什麼時候你是基於資源名稱涉及一個或多個資源，而不是檢查是否資源有一個ID尋找以下
複數有時對於非母語困難時（不只是一個「s」）
的URL較長
的「S」似乎是一個多餘的路徑參數從程序員的立場
只是尷尬考慮路徑參數的集合的子資源，而不是考慮它是什麼：僅僅是資源的ID是識別

來源

2014-06-24 06:21:30 arpadf

*「將路徑參數視爲集合的子資源只是尷尬」*爲什麼？如果建模正確，則URL會正確表示層次結構。就我個人而言，我覺得如果*這樣的資源在多個地方可用，它會變得很尷尬。但只要有一個「擁有」資源，我認爲這是完全合理的。 '/ books/of-men-and-mice/chapters/1'或'orders/12543/orderlines/2'，或'places/EU/nl/Amsterdam'等。你應該避免以這種方式映射所有關係，只是「擁有」關係（通常在DB中設置ON DELETE CASCADE）。 – 2017-06-27 19:29:17

我對使用複數形式並不陌生，但像「/ orders/1234」這樣的例子與我不一致：order是複數，而1234是一個唯一的id，因此表示一個單數對象。在我看來，所有訂單和由ID 1234標識的訂單都代表一個資源（集合）。不是兩個。你可能會爭辯說，單一資源是整體的一個子集，我可以接受，但這是一種人爲的層次結構。 – arpadf 2017-06-29 15:51:28

那麼，我的收集端點只是返回一個數組。如果我要定義一個數組，它也將以複數形式命名。例如。'var books = [{title：'男人和老鼠'}，{..}，{..}]'。所以對我來說感覺非常一致。 – 2017-06-30 23:07:43

REST風格的帖子，你是否將單個對象設置爲單數或複數Uri？

回答

相關問題