前言

上一篇的文章Request Drivne Architecture介紹，我們說明Request Driven的由來與運作流程。

這一篇的文章著重講RESTFul API:

• 未使用RESTFul API協定的形式以及缺陷
• 引入RESTFul API的好處
• 舉例比較兩者的區別

好了～讓我們開始吧！

Non-RESTFul

Non-RESTFul API基本不會遵循HTTP/HTTPS的協定，API的URL可以隨意亂命名，像是

• GET /getOrder
• GET /getList?id=1
• GET /getAllListById?id=1

這樣的命名規則不僅讓團隊的成員們看得霧颯颯，甚至還開出功能一樣的API，這會讓團隊的開發效率大大地降低，溝通成本變的非常高！甚至最後還會吵起來！！

我們簡單舉個實際的訂單系統為例:
假設今天客戶有個查看購物車內容的需求，我們根據這個需求列出以下兩項：

1. API規格：GET
2. 前端攜帶兩個path parameters: userId以及orderId

有了這兩項之後，我們可以進一步開出查看購物車內容的API Spec，沒有使用RESTful的Request Driven的API如下所示：

api/getOrderDetails/user/{userId}/order/{orderId}

這種命名規則有幾個缺陷:

1. 可讀性不佳：URL包含這隻API的行為getOrderDetails，造成開發人員的可讀性降低，不易維護。
2. 擴展性不佳：若需要增加更多API的行為與操作，會使用更多類似getOrderDetails的動詞形式，讓URL變的更加複雜。
3. 一制性不佳：不同的開發人員對同一隻API有不同的命名規則，造成團隊間對API的認知不同，影響團隊開發與合作。

這些缺陷不僅讓團隊的成員看得霧颯颯，心裡會想getOrderDetails是什麼？
是拿list嗎？還是一個具有多個欄位的json?

顯然這種命名方法不是很恰當，對吧！
為了要解決這些問題，RESTFul API就誕生了。

RESTFul API

RESTFul(Representational State Transfer) API是一種基於Ｗeb設計的風格，它用於建立可擴展而且好維護的Web服務，在Ｗeb中很受歡迎的一種設計風格，在微服務同樣也是如此。

為什麼RESTFul這麼受歡迎？

原因是RESTFul的主要目的就是讓Web服務更加簡潔明瞭、好理解和統一的一種設計風格或者說是協定。

有點抽象對吧？我們同樣以訂單系統為例：

[GET] api/users/{userId}/orders/{orderId}

相比於Non-RESTFul將getOrderDetails這種具有動詞含義加進API，而是採用[GET]的統一風格讓大家理解這隻是GET的API，並帶兩個參數: userId與orderId，讓團隊對這隻API的理解不會搞錯。

甚至可以基於[GET]延伸到[POST], [PUT]

[POST] api/users
[PUT] api/users

RESTFul的優點：

1. 可讀性佳: URL沒有包含API的行為，很好理解和維護
2. 擴展性佳: 通過統一的風格[GET]、[POST]、[PUT]、[DELETE]能輕易的擴展出不同的API，而不是讓URL變的很複雜
3. 一致性佳: 使用統一的命名規則與結構，透過一致的API能提升團隊的開發與合作效率。

總結

舊系統中或許還存在Non-RESTFul的設計風格，由於它的缺陷讓它不適合應用到現代的軟體開發，我們可以通過引入RESTFul API的設計風格，可以提高API的可讀性、可維護性和可擴展性。

好了～～今天就到這邊！！！
明天會開講Request Driven的缺點～