RESTfulness用單一入口點

我已經與所有客戶端請求一個網關面向服務的體系結構。我喜歡這一點，因爲網關很整潔，隱藏了所有「內部」服務，並充當調度員和自制負載均衡器。RESTfulness用單一入口點

因爲我設計的，但是，客戶端永遠只知道「一個」資源。並且必須發送請求操作的消息及其在JSON中定義的參數。

{ 
    "operation" : "Login", 
    "parameters" : 
    { 
     "username" : "John", 
     "password" : "1234" 
    } 
}

我應該因爲我的架構不是RESTful而感到難過嗎？我沒有像REST那樣使用HTTP嗎？請批評。

來源

2011-07-26 S. Valmont

我不知道，如果「傷心」是正確的字，但贊成REST的參數之一，尤其是在使用HTTP來實現「正確」是它提供給你，是免費的，以下（從Fielding的論文采用）：

客戶端 - 服務器交互，從數據存儲中分離UI
無國籍服務器，提高可靠性和可擴展性
客戶端緩存，減少一些網絡流量
統一接口，解耦實現從se rvices他們提供
分層系統，其中每個組件只關心那些略低於或略高於它
表示方向，您認爲在資源方面
HATEOAS，您的應用程序主要導航鏈接
一個受約束的接口，帶有少量動詞（例如， GET，PUT，POST，DELETE，只有其他約3個）

當您使用SOAP或其他RPC解決方案而不是REST時，理論上放棄了一些但不是全部這些特徵。您可能會放棄客戶端緩存能力，並且您正在按照程序進行思考，並且您可能無法使用RESTafarians利用的所有安全和冪等條件。

RESTful服務已經成爲事故非常受歡迎的，而不是。但這是否意味着你有有來構建RESTful服務，或者非RESTful服務本質上更糟？我不這麼認爲。我爲兩家不同的公司做了一些RESTful SOA，雖然我更喜歡SOAP（這些看起來很笨重），並且喜歡像你們這樣的本土API（即使是優雅的，不是標準的），但我不消除其他方法並將它們視爲劣等。

如果你打算去與自己的API，並返回只有200秒和404，並用GET做的一切，然後是你的API的概念很簡單，也許它會正常工作適合你。但是，如果您需要各種媒體類型，而且您的持久存儲需求包含經常附加到，刪除，創建和更新的集合，那麼學習現代RESTful API設計至少會爲您開創新的思維方式。

底線不會感到悲傷，也不覺得你必須去REST，因爲其他人都在這樣做。但優點是真實的，REST不只是炒作。

來源

2011-07-26 05:04:50

謝謝。作爲讓我的上述服務更加RESTful的假設起點，你會改變什麼？您是否會向相同的登錄服務發送相同的JSON，並獲取進一步繼續處理的URL列表（即代表客戶成功驗證後可用的操作的鏈接）？與哪個動詞（即GET，POST，PUT或DELETE）一起使用哪個URL？問題向所有人開放。 –

你能舉出一些其他「服務」的例子嗎？登錄是更傳統的RESTful服務只是留給瀏覽器，以響應接收401。 –

http://myordersystem.com/myorderservice.svc/CreateNewOrder（POST） –

沒有。基本上，你有一個家庭釀造的SOAP風格的RPC使用JSON而不是XML。

您可能會問，是否值得重新改造JSON而不是使用SOAP堆棧，但如果您正在使用JavaScript進行交互，那麼使用它可能比SOAP更容易使用，並且沒有與SOAP相符的負擔標準/工具集。

除此之外，似乎沒什麼問題。

來源

2011-07-26 04:39:57

沒有將所有我的服務作爲獨立和獨立的URL提供，沒有辦法認爲自己是RESTful，是嗎？當然，暴露10個分佈式服務的安全性問題比暴露一個服務器更多，而讓其他9個服務器位於防火牆後面，對嗎？ –

REST有很多限制，但是多個URL是其中之一，因爲資源是通過URL進行建模的。 –

RESTfulness用單一入口點

回答

相關問題