REST API的設計風格是什么樣的

REST API的設計風格是什么樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

　　有些人可能會強烈反對上面提到的/translate和其他JSON路由是API路由。其他人可能會同意，但也會認為它們是一個設計糟糕的API。那么一個精心設計的API有什么特點，為什么上面的JSON路由不是一個好的API路由呢？

　　你可能聽說過RESTAPI。REST（RepresentationalStateTransfer）是RoyFielding在博士論文中提出的一種架構。該架構中，Dr.Fielding以相當抽象和通用的方式展示了REST的六個定義特征。

　　除了Dr.Fielding的論文外，沒有關于REST的權威性規(guī)范，從而留下了許多細節(jié)供讀者解讀。一個給定的API是否符合REST規(guī)范的話題往往是REST“純粹主義者”之間激烈爭論的源頭，REST“純粹主義者”認為RESTAPI必須以非常明確的方式遵循全部六個特征，而不像REST“實用主義者”那樣，僅僅將Dr.Fielding在論文中提出的想法作為指導原則或建議。Dr.Fielding站在純粹主義陣營的一邊，并在博客文章和在線評論中的撰寫了一些額外的見解來表達他的愿景。

　　目前實施的絕大多數(shù)API都遵循“實用主義”的REST實現(xiàn)。包括來自Facebook，GitHub，Twitter等“大玩家”的大部分API都是如此。很少有公共API被一致認為是純REST，因為大多數(shù)API都沒有包含純粹主義者認為必須實現(xiàn)的某些細節(jié)。盡管Dr.Fielding和其他REST純粹主義者對評判一個API是否是RESTAPI有嚴格的規(guī)定，但軟件行業(yè)在實際運用中引用REST是很常見的。

無狀態(tài)

　　無狀態(tài)原則是REST純粹主義者和實用主義者之間爭論最多的兩個中心之一。它指出，RESTAPI不應保存客戶端發(fā)送請求時的任何狀態(tài)。這意味著，在Web開發(fā)中常見的機制都不能在用戶瀏覽應用程序頁面時“記住”用戶。在無狀態(tài)API中，每個請求都需要包含服務器需要識別和驗證客戶端并執(zhí)行請求的信息。這也意味著服務器無法在數(shù)據(jù)庫或其他存儲形式中存儲與客戶端連接有關的任何數(shù)據(jù)。

　　如果你想知道為什么REST需要無狀態(tài)服務器，主要原因是無狀態(tài)服務器非常容易擴展，你只需在負載均衡器后面運行多個服務器實例即可。如果服務器存儲客戶端狀態(tài)，則事情會變得更復雜，因為你必須弄清楚多個服務器如何訪問和更新該狀態(tài)，或者確保給定客戶端始終由同一服務器處理，這樣的機制通常稱為粘性會話。

　　再思考一下本章介紹中討論的/translate路由，就會發(fā)現(xiàn)它不能被視為RESTful，因為與該路由相關的視圖函數(shù)依賴于Flask-Login的@login_required裝飾器，這會將用戶的登錄狀態(tài)存儲在Flask用戶會話中。

客戶端－服務器

　　客戶端－服務器原則相當簡單，正如其字面含義，在RESTAPI中，客戶端和服務器的角色應該明確區(qū)分。在實踐中，這意味著客戶端和服務器都是單獨的進程，并在大多數(shù)情況下，使用基于TCP網(wǎng)絡上的HTTP協(xié)議進行通信。

分層系統(tǒng)

　　分層系統(tǒng)原則是說當客戶端需要與服務器通信時，它可能最終連接到代理服務器而不是實際的服務器。因此，對于客戶端來說，如果不直接連接到服務器，它發(fā)送請求的方式應該沒有什么區(qū)別，事實上，它甚至可能不知道它是否連接到目標服務器。同樣，這個原則規(guī)定服務器兼容直接接收來自代理服務器的請求，所以它絕不能假設連接的另一端一定是客戶端。

　　這是REST的一個重要特性，因為能夠添加中間節(jié)點的這個特性，允許應用程序架構師使用負載均衡器，緩存，代理服務器等來設計滿足大量請求的大型復雜網(wǎng)絡。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業(yè)資訊頻道，感謝您對億速云的支持。