我需要創建一個端點，它將提供一個對象列表，我需要通過作爲請求身份列表我想要檢索的對象的ID。據我所知，這應該通過GET方法來完成，因爲它只是檢索對象而不是修改它們，但是當我想從客戶端使用RestTemplate調用它時，它沒有任何方法可以讓GET傳遞主體。但是，這可以通過POST方法實現。我應該使用POST而不是GET還是有其他解決方案？將參數列表作爲body或POST方法獲取方法？
編輯：爲大家的simmilar問題，這個線程有很大幫助：
如果你要堅持GET這是語義上更正確的，你需要通過ID作爲一個列表由於GET未定義正文，因此請求參數而非正文。
使用POST在這種情況下，您可以傳遞列表在主體中，通常也可以，但也有一些粘貼者會聲明它在語義上不正確。
請注意，POST有時是首選，這取決於查詢數據的複雜程度或長度。
的GET請求消息內的有效載荷不具有確定的語義;在GET請求上發送有效內容主體可能會導致一些現有的實現拒絕請求。
這消除了GET作爲一個選項; HTTP根本不支持你想要做的事情。
我需要傳遞作爲請求的身體列表我要檢索的對象的身份列表。
GraphQL作爲web apis的查詢語言正在獲得一些吸引力。這是同樣的問題;一個複雜的查詢。例如，Github正在實現一個graphQL端點，它可以產生比REST更RPC的api。所以就這樣了。
這一點適用於您的問題，即通過POST進行查詢，因爲模式確實存在爲模式。
還有其他解決方案嗎？
有可能更好地爲您
如何網頁加載多個圖像的一些替代設計？一次一個。這種方法的一個優點是緩存 - 網頁可以重複使用之前看到的圖像的表示。這提供了REST架構約束所承諾的一些改進的縮放比例。
將此與詢問對象列表的表示形式進行比較，每次更改列表中的項目或每次單個項目更改其表示時，表示都必須更改。
你可以使用ID本身作爲URI的一部分，也就是說如果你想要的是一個對象列表的表示，那麼對象列表可能是它自己的概念（資源）標識符。
這種方法可能在以下兩種方式之一表現。你可能會保持id列表是明確的（使概念本身是隱含的），換句話說，通過枚舉URI本身的id。
或者，你可以嘗試做概念明確在你的設計 - 弄清楚爲什麼客戶端是要求IDS的特定組合，並創建一個代表這個概念的資源。例如：如果客戶端是採摘的ID，因爲他們有共同的（所有打開的門票）的一些屬性，那麼這個概念是一個集合的該屬性過濾 - 讓您將創建一個開放的車票資源。同樣，如果由於客戶端正在通過結果進行分頁而出現id列表，那麼您可以使分頁明確（此方法在Feed中常見，請參閱AtomSyndication）。
總之，你可能很難找到一個休息的好答案，因爲你有錯誤的問題。
使用IDS作爲URI的一部分是不是在我因爲ID的複雜性的情況下的選擇，這將導致有時是優選在某些情況下超過4.000個字符的URI，我相信並不是完美的解決方案。 （處理這樣長的URI可能導致網絡瀏覽器的一些麻煩） 二計算策略顯得很intresting，其幾乎完全這種情況下，唯一的區別是，我想開出來的票票的一些池（由1-全部門票1000），我只想從1,5,71,189等游泳池打開門票。對於這種情況，什麼方法是完美的？ –
這是什麼意思，客戶選擇1,5,71,189而不是1,6,711,189？隱藏的想法隱藏在那裏？是否明確幫助解決問題？ – VoiceOfUnreason
注意'POST'取決於如何複雜，長甚至** **敏感的查詢數據 –