您可以說HTTP REST請求是Web的命令行：它會調用特定服務並提供有關如何執行該服務的詳細信息。有沒有用於將HTTP REST請求映射到命令行參數的標準或軟件？
事實上，很多Web服務調用轉換爲創建一個子進程，交給它的一些相應的參數，並且複製標準輸出回HTTP客戶端。例如，在線執行Microsoft Word到PDF轉換的服務可能具有此工作流程。
在某些情況下，它似乎是多餘的定義一個新的HTTP API時，命令行實用程序都有自己的有效的接口。是否有任何標準在這裏定義，或任何軟件，幫助「automagically」包裝命令行工具與HTTP REST和協助輸入驗證細節？
據我所知，沒有標準的方法來做到這一點。這取決於您提供的服務，您需要的參數和您期望的結果。有一些準則和良好做法設計的REST API但沒有什麼直接關係到你所提到的。
重要的是要記住REST架構使用client-server model和它的協議無關。然而，最常見的方法是通過HTTP protocol來設計它。
一個REST API基於HTTP協議提供URI S作爲uniform interface爲您服務，並使用standard HTTP methods，使服務從支持HTTP多個客戶端調用。
在REST API中，您可以提供不同的資源表示，如JSON或XML，客戶端可以根據需要請求最合適的表示。 API調用可能會受到每個用戶的限制，或者他們可能因使用您的服務而被收費。
根據定義，REST應用stateless。這意味着客戶端到服務器的每個請求都必須包含服務器必須理解的所有信息，而不是利用服務器上存儲的任何上下文。會話狀態因此完全保留在客戶端上。
據羅伊·托馬斯·菲爾丁，誰定義REST是如何應該是這個傢伙，在stateless約束誘導知名度，可靠性和可擴展性的屬性：
能見度因爲監控系統不必超出單個請求數據的範圍，以確定請求的全部性質。 可靠性得到了改進，因爲它簡化了從部分故障中恢復的任務。 可伸縮性得到了改進，因爲不需要在請求之間存儲狀態，服務器組件可以快速釋放資源，並且進一步簡化了實現，因爲服務器無需管理跨請求的資源使用情況。
的stateless做法也反映了設計權衡：
的缺點是，它可以通過增加重複數據（每互動的開銷）在一系列請求發送降低網絡性能，因爲這些數據不能留在共享上下文中的服務器上。另外，將應用程序狀態放在客戶端可以減少服務器對一致的應用程序行爲的控制，因爲應用程序依賴於跨多個客戶端版本的正確語義實現。