REST 正在消亡，擺脫它吧

自 1980 年代以來，我一直在為計算機程式設計。

在那段時間裡，我看到並使用了很多來來去去的語言和技術。

我看到 Web 出現了新功能，例如非同步交換 XML 資料的瀏覽器。

今天我們將這種

非同步 JavaScript 和 XML

資料交換稱為“AJAX”，但具有諷刺意味的是，AJAX 通常甚至不再使用 XML。

大多數情況下，這些資料以 JSON、YAML、HTML 或其他格式交換。

1996 年，微軟工程師在 IE4 中引入了 iframe 標籤。

這允許瀏覽器在不重新整理頁面的情況下與相同或完全不同的伺服器非同步交換資料，並且可以將資料傳遞給生成 iframe 物件的父物件。

當時，新功能對我來說似乎只是一個神奇的“框架”功能（我知道，你不知道什麼是 HTML 框架；是的，我已經那麼老了，謝謝提醒）。

然而，我的兄弟在 1990 年代中期在商業專案中使用這項技術來做到這一點——甚至在“AJAX”一詞被髮明之前就使用 XML 進行“AJAX”資料呼叫。

幾年後，微軟將

XMLHttpRequest

在 IE5 中建立該物件。

其他瀏覽器廠商紛紛效仿，“AJAX”時代誕生了。

REST 正在消亡，擺脫它吧。

有時，標準和技術的發明源於以下原因：好的、壞的和醜陋的。

REST 是體現所有三個標準的標準之一：好的、壞的和醜陋的。

但是每個人都在繼續使用 REST，因為這是現代客戶端（瀏覽器）實現的。

我對 REST 的主要問題是它的

動詞：GET、POST、PUT、DELETE 等

，限制太多，

響應通常不一致

，或者根本沒有響應，就像 DELETE 一樣。

是的，您

可以

透過 DELETE 呼叫傳送成功響應（即資料有效負載），但這並不是真正的標準。

哦，

你得到了 200 響應，這意味著它有效。不是。也許它做到了，也許它沒有。傳送 202 或 204 響應可能同樣神秘。

公平地說，REST 實際上並不是一個數據交換協議，例如 SOAP。

它實際上是一種建築風格，或者有人會說“模式”。

作為軟體開發人員，有時我們明確地遵循樣式/模式，有時我們不這樣做。

標準是好的，如果他們工作。

但隨著技術使用的進步，“標準”通常開始阻礙你，這就是 REST 對 Web 所做的事情。

除了動詞的限制之外，我對 REST 的許多問題中的另一個是它的端點。誰認為擁有 37 個不同的端點是個好主意？

REST 也不像 SOAP 和 WSDL 那樣本機實現 API 文件。

是的，OpenAPI 規範（以前稱為 Swagger）試圖解決這個問題，但它是另一個 REST 附加元件。

由於 REST 的這個和其他限制，許多軟體工程師使用小部分 REST 和/或借鑑其他更好的協議來開發和發展我們自己的 Web 服務版本，我也不例外。

TIGER：更簡單、效果更好的 Web 服務

TIGER 是我為大約 12 年前開發的一個鬆散的 Web 服務標準而創造的一個名稱，因為我厭倦了 REST 的限制和廢話。

TIGER 鬆散地基於一種

JSON-RPC

（JSON 遠端過程呼叫）協議，它實際上只是使用 REST 的 POST 和/或 GET 動詞透過瀏覽器客戶端傳送和接收資料。

如果您願意，GET 用於快速獲取資料，但 POST 幾乎專門用於安全地交換資料。

TIGER 利用易於使用的“訊息模式”將資料傳送和路由到需要去的地方。

路由元資料包含（混合）在發往伺服器的“訊息”中。

因此，TIGER 真的只需要一個端點。

是的，您可以擁有多個端點，但您不應該這樣做。

就像我們在典型的 RESTful 服務中看到的那樣，擁有具有多個端點的 API 會產生巨大的程式碼膨脹。

Zend 甚至建立了一個名為“Apigility”的完整 REST 框架來管理和進一步膨脹 API 端點。

這是胡說八道。

保持簡單的事情發生了什麼？

TIGER 真正閃耀的地方在於面向服務的 MVC 應用程式的上下文中。

您的 AJAX 資料訊息無需設定多個端點，而是僅包含 MVC 的控制器/操作，或者在 SOA（面向服務的架構）的情況下，您希望針對資料有效負載進行處理的服務/方法。

繁榮！

完畢。

如果您願意，您還可以在訊息元資料中包含版本屬性等內容，以針對特定的服務版本。

TIGER Webservices 背後的主要目標是：

為 API 建立一個單一且安全的入口點，這樣我就不必管理和維護數十個版本化的端點，從而使我的程式碼膨脹。

自動驗證、路由和授權來自 API 的請求。

在客戶端和伺服器的訊息和響應之間建立一個靈活但又一致的契約。

TIGER 服務通常是有狀態的。

但如果你願意，它們可以是完全無國籍的。

您不會限制某人對 API 應該如何表現的想法。

在 MVC 的上下文中執行的 TIGER 必須將每個匿名請求驗證為“訪客”，或者作為其他經過身份驗證的角色來進行授權。

如果你無權訪問你請求的任何資源，你就不會進入。

在這方面，TIGER Web 服務確實依賴於客戶端維護某種會話狀態，但無論如何我們已經對各種 RESTful 服務做到了這一點，所以 TIGER 在這方面沒有什麼不同。

TIGER Web 服務在行動

這裡的概念非常簡單。

這就是圖案的美妙之處：

這是使用 jQuery 呼叫的典型 TIGER AJAX 請求的樣子：

$。ajax（{

type ： ‘POST’，

url ： ‘/api’，

dataType ： ‘json’，

data ： {

service ： ‘user’，

method ： ‘save’，

firstname ： ‘Thundarr’，

lastname ： ‘Barbarian’

}，

beforeSend ： beforeSend，

complete ： complete，

success ： success，

error ： error

}）；

請注意，

beforeSend

、

complete

、

success

和

error

只是表示將處理這些 AJAX 事件的函式的 JavaScript 變數。

在這個簡單的示例中，我們看到我們將 JSON 資料釋出到伺服器的唯一

/api

端點。

TIGER API 服務期望在訊息資料中看到的是“服務”和“方法”屬性。

然後它將整個訊息資料物件路由到該特定服務和方法。

您還可以傳遞“控制器”和“動作”屬性，TIGER 會將資料路由到 MVC 中任何控制器的特定操作。

在這個示例呼叫中，我們聯絡“user”服務的“save”方法以將使用者的“firstname”和“lastname”欄位儲存在資料庫中。

沒有比這更簡單的了。

TIGER API 路由

每個 API 呼叫都透過 API 服務進行路由。

API 服務實現了一個基本的工廠模式來進行一些健全性檢查、驗證、授權，然後例項化請求的控制器或服務。

在 TIGER 平臺的情況下，我使用 PHP 的

__construct（）

方法將整個訊息傳遞到構建時的服務中，並讓服務將訊息從那裡路由到任何方法。

以這種方式處理資料很酷的一點是，當新例項化的服務最終返回時，所有工作都已經完成，我需要做的就是呼叫服務的

getResponse（）

方法來獲取響應負載，然後我們就完成了。

好的，所以它只是在工廠流程中為我節省了一步，但它仍然是在 PHP 中實現 SOA 的一種巧妙的可擴充套件方式。

但我離題了……

TIGER

響應

TIGER 的美妙之處在於我每次都返回完全相同的響應物件。

該響應物件始終具有我期望的屬性。

它就像一個介面，一個客戶端和伺服器之間的契約。

在響應物件中，我知道我總能找到至少以下屬性：

{

result ： 1， // or 0 on error

data ： { 。。。 }， // 也可以是陣列

messages ： ［‘一個或多個訊息的陣列，如果有的話。’］，

error ： ［ 表單陣列錯誤，如果有的話］

}

但是您也不僅限於一種型別的響應。

例如，DataTables 和 Select2 要求我返回不同型別的響應以供它們使用。

沒問題。

對於這些型別的資料請求，我有單獨的一致響應物件來發回。

把它們放在一起

我不想在本文中釋出大量程式碼，因此，如果您想了解 TIGER Webservices 的執行情況，請檢視 GitHub 上使用這些服務的 TIGER 平臺。

這裡有幾個連結：

呼叫 TIGER 服務的典型但簡單的外掛：

Tiger/core。admin。cache。js at master · WebTigers/Tiger （github。com）

TIGER Webservice API 服務工廠：

Tiger/ServiceFactory。php at master · WebTigers/Tiger （github。com）

請注意，上面的程式碼是受版權保護的，因為它是商業產品的一部分，但模式本身不受版權保護。

隨意“借用”這些想法並編寫自己的版本。

TIGER 程式碼是專門公開的，因為我希望人們瞭解 TIGER Webservices 的易用性以及它們如何使每個人在構建 Web 服務時的生活更輕鬆。

TIGER

發現

雖然我還沒有為 TIGER 實現 OpenAPI 風格的“發現”模式或標準，但您可以看到，使用 TIGER 的訊息模式只需傳入一個元資料屬性，告訴 TIGER 返回任何 API 文件和響應模型型別，就可以使發現變得基本你想要。

如果您需要實現公共 API，這不是一個難以解決的問題。

結論

隨著網路的不斷髮展，REST 正在並且應該隨著新的更好的想法的出現而慢慢消亡。

JSON 幾乎完全取代了 XML。

微服務正在成為更單一的面向服務架構的更流行的變體；

等等。

現在是我們超越 REST 並獲得更大靈活性的時候了。

如果可以避免的話，我不會使用純 RESTful 服務。如果沒有其他原因，這樣的程式碼太膨脹

了。

有些人可能會爭辯說，TIGER網路服務太 “

鬆散

”了，沒有遵守任何 “公認 ”的標準。你是對的，他們沒有，而且有充分的理由。我不喜歡我所看到和使用的標準。它們很糟糕。所以我不使用它們。作為一個應用架構師，我寫我自己的。你也可以。你不必因為其他人都這樣做而使用一些古怪的過時的標準。

您的用例應該驅動技術，而不是相反。

關鍵是，僅僅因為某些東西是所謂的“公認”標準並不意味著它是完美的，或者它最適合您的應用程式的用例。

經驗會告訴你什麼是最好的，什麼不是。

某些東西不一定是“公認的標準”，只要它有良好的文件記錄並針對您的獨特用例簡化您的程式碼即可。

現在有比 REST 更好的模式和協議在客戶端和伺服器之間交換資料。

檢視 TIGER Webservices 及其工作原理。

他們可能只是給你一些你自己的想法，這些想法可以讓其他工程師在一兩年後的編碼變得更加容易。

____________________

Beau Beauchamp 是一名 Web 應用程式架構師，擁有 20 多年在雲中開發企業級應用程式的經驗；

他是

WebTigers

的創始人和 Tiger 平臺背後的首席開發人員。