我正在寫一個只做一件事的小應用程序：獲取一些用戶提供的數據，對其進行一些分析，然後爲該數據返回一個「標記」。我想客戶應該要麼GET要麼POST他們的要求/getTag爲了得到迴應。正確的RESTful方式來處理一個請求，而不是真的創建或獲取某些內容？
客戶端執行此操作時，服務器上不存儲任何內容，因此使用POST時感覺很奇怪。但是，分析也沒有統一的URI，因此使用GET會感到奇怪，因爲它會根據提供的數據返回不同的內容。
用REST表示這個功能的最好方法是什麼？
POST可以表示執行操作。行動不有是一個數據庫操作。
你真正創建的是一個遠程過程。 RPC通常都是POST。我認爲這不適合REST，但這並不妨礙您使用簡單的URL和JSON。
「最好的辦法」是做任何最適合您應用程序及其需求的方法。不知道的是，這裏有一些想法：
GET是最合適的動詞，因爲你沒有創建或服務器上存儲任何東西，只是檢索一些服務器提供。
請不要將字get放在URI中，就像您建議的那樣。像這樣的動詞已經由HTTP提供，所以只需使用/tag和GET即可。
你應該對這個資源使用一個很好理解的（或「酷」）URI並且傳遞數據作爲查詢參數。我不會擔心它感覺奇怪（請參閱this question's答案以找出原因）。
綜上所述，只是GET上/tag?foo=bar&beef=dead，就大功告成了。
在我看來，似乎可能有一個原因，你或用戶誰產生的原始數據會希望生成的標籤堅持下去，不是嗎？
如果這是有可能的，那麼我會寫爲POST /tags並通過/tags/:id資源URI早在Location：頭。
如果我真的不在乎持久化生成的標籤，我會考慮「用戶生成的數據」是什麼以及幕後發生了多少處理。如果「標籤」與傳遞給系統的數據不同，GET /tag可能會讓API消費者感到困惑。
我會第二個布賴恩的答案：使用GET。如果相同的輸入參數返回相同的輸出，並且您沒有真正創建任何內容，則這是一個冪等動作，因此完全適合於GET。
可以使用GET和POST或者：
GET /tag?data="..." -> 200, tag
GET方法意味着檢索的任何信息（以一個 實體的形式）由請求URI來標識。如果Request-URI引用數據產生過程，則產生的數據應作爲響應中的實體而不是 過程的源文本返回，除非該文本恰好是處理。
POST /tag {data: "..."} -> 200, tag
由POST方法可能不會導致資源 可以通過URI標識的行動。在這種情況下，200（OK）或204 （無內容）是合適的響應狀態，具體取決於 是否包含描述結果的實體。
根據HTTP標準/ method definitions部。
如果我是你，我會使用GET（如果你想發送文件，則使用POST）。