RESTful
百度百科上說：RESTful一種軟體架構風格、設計風格，而不是標準，只是提供了一組設計原則和約束條件。它主要用於客戶端和伺服器互動類的軟體。基於這個風格設計的軟體可以更簡潔，更有層次，更易於實現快取等機制。
wikipedia上說：(REpresentational State Transfer, REST)是一種架構風格，它定義了一組基於HTTP的約束和屬性。符合REST架構風格或RESTful 的Web服務提供了Internet上的計算機系統之間的互操作性。遵從REST的web服務允許通過使用統一和預定義的無狀態請求來訪問和操作web系統的資源。【翻譯不準確請多多包含】
需要注意的是，具象狀態傳輸是設計風格而不是標準。REST通常基於使用HTTP，URI，和XML以及HTML這些現有的廣泛流行的協議和標準。
- 資源是由URI來指定。
- 對資源的操作包括獲取、建立、修改和刪除資源，這些操作正好對應HTTP協議提供的GET、 POST、PUT和DELETE方法。
- 通過操作資源的表現形式來操作資源。
- 資源的表現形式則是XML或者HTML，取決於讀者是機器還是人，是消費web服務的客戶軟體還是web瀏覽器。當然也可以是任何其他的格式。
指導性約束定義了一個RESTful系統。這些約束限制了伺服器處理和響應客戶請求的方式，以便通過在這些約束內操作，服務獲得期望的非功能屬性，例如效能，可伸縮性，簡單性，可修改性，可見性便攜性和可靠性。如果某個服務違反了任何所需的約束條件，則不能將其視為RESTful。
客戶端 - 伺服器【客戶端 - 伺服器模型】 客戶端 - 伺服器約束背後的原則是分離關注點。將使用者介面問題與資料儲存問題分開可以改善跨多個平臺的使用者介面的可移植性。它還通過簡化伺服器元件來提高可伸縮性。然而，對網路而言，最重要的可能是分離允許元件獨立發展，從而支援多個組織域的Internet規模需求。
無狀態【無狀態協議】 客戶端 - 伺服器之間的通訊受限於在請求之間沒有客戶端上下文儲存在伺服器上。來自任何客戶端的每個請求都包含為請求提供服務所需的所有資訊，並且會話狀態儲存在客戶端中。會話狀態可以由伺服器傳輸到另一個服務（如資料庫），以維持持續狀態一段時間並允許進行身份驗證。客戶端在準備好轉換到新狀態時開始傳送請求。儘管一個或多個請求未完成，但客戶端仍處於轉換中。每個應用程式狀態的表示包含下次客戶機選擇啟動新狀態轉換時可能使用的連結。
可快取性【Web快取】 就全球資訊網而言，客戶和中介可以快取響應。因此，響應必須隱含地或明確地將其自身定義為可快取或不阻止客戶端響應於進一步的請求而重用過時或不適當的資料。管理良好的快取部分或完全消除了一些客戶端 - 伺服器互動，進一步提高了可伸縮性和效能。
分層系統【分層系統】 客戶通常無法判斷它是直接連線到最終伺服器還是直接連線到中間人。中介伺服器可以通過啟用負載平衡和提供共享快取來提高系統可擴充套件性。他們也可能會執行安全策略。
統一介面 統一的介面約束是任何REST服務設計的基礎。它簡化和分離了架構，使每個部分獨立演變。這個統一介面的四個約束是：
-
請求中的資源標識 在請求中標識各個資源，例如在基於Web的REST系統中使用URI。資源本身在概念上與返回給客戶端的表示分離。例如，伺服器可以從其資料庫傳送資料為HTML，XML或JSON，其中沒有一個是伺服器的內部表示。
-
通過表示進行資源處理 當客戶端持有資源的表示形式（包括附加的任何後設資料）時，它具有足夠的資訊來修改或刪除資源。
-
自描述性訊息 每條訊息都包含足夠的資訊來描述如何處理訊息。例如，要呼叫哪個解析器可以通過Internet媒體型別（以前稱為MIME型別）指定。
-
超媒體作為應用程式狀態的引擎（HATEOAS） 在訪問REST應用程式的初始URI（類似於訪問網站主頁的人類Web使用者）後，REST客戶端應該能夠動態地使用伺服器提供的連結來發現所需的所有可用操作和資源。隨著訪問的進行，伺服器以包含超連結的文字進行響應，該超連結指向當前可用的其他操作。客戶端不需要對關於REST服務的結構或動態的資訊進行硬編碼。
RESTful API
剛入門php的時候，不知道這麼多道道，覺的能訪問這個檔案了就算成成功了。那時候URL是這樣的：
https://example.com/balabala.php?resources=233&fdsafdafdfa=......
後來，接觸第一款框架Laravel，突然看到這種URL：
https://example.com/resources/233/fdsafdafdfa/.......
頓時覺的眼前一亮，舒服。但是不知道這兩者之間有啥區別，隨著框架的一步步的深入使用和學習。首先是nginx/apache配置方面的問題【比較老的框架我就不知道是什麼情況了】，沒有使用框架的時候，是使用web伺服器來進行訪問PHP檔案URL如下：
test/ ----- 專案資料夾
├── Cl.php ----- url：http://www.test.com/Cl.php?param=...
├── index.php
└── te
└── iiii.php ----- url: http://www.test.com/te/iiii.php?param=...
複製程式碼使用框架之後，nginx配置統一指向public資料夾下的index.php入口檔案。URL解析的工作不再由web伺服器負責。而是改為使用PHP自身來負責，根據相應的URL如:http://www.test.com/id/1結合mvc或者是其他的設計模式來進行資源的解析和載入【具體的方式這裡不提，請自行查閱文件】。
遵循REST架構約束的 Web服務API稱為RESTful API。基於HTTP的RESTful API定義了以下幾個方面：
- 基本URL，例如
http://api.example.com/resources - 定義狀態轉換資料元素的網際網路媒體型別（例如： Atom, microformats, application/vnd.collection+json）。當前表示告訴客戶如何編寫轉換到所有下一個可用的應用狀態 這可以像URL一樣簡單，也可以像Java applet一樣複雜。
- 標準的HTTP方法（例如，OPTIONS，GET，PUT，POST和DELETE）
| (URL) | GET | PUT | PATCH | POST | DELETE |
|---|---|---|---|---|---|
https://api.example.com/resources/ |
從伺服器取出資源（一項或多項）。 | 在伺服器更新資源（客戶端提供改變後的完整資源）。 | 在伺服器更新資源（客戶端提供改變的屬性）。 | 在伺服器新建一個資源。 | 從伺服器刪除資源。 |
下面是一些URL示例
這樣
* GET /tickets - Retrieves a list of tickets
* GET /tickets/12 - Retrieves a specific ticket
* POST /tickets - Creates a new ticket
* PUT /tickets/12 - Updates ticket #12
* PATCH /tickets/12 - Partially updates ticket #12
* DELETE /tickets/12 - Deletes ticket #12
或者這樣
* GET /tickets/12/messages - Retrieves list of messages for ticket #12
* GET /tickets/12/messages/5 - Retrieves message #5 for ticket #12
* POST /tickets/12/messages - Creates a new message in ticket #12
* PUT /tickets/12/messages/5 - Updates message #5 for ticket #12
* PATCH /tickets/12/messages/5 - Partially updates message #5 for ticket #12
* DELETE /tickets/12/messages/5 - Deletes message #5 for ticket #12
複製程式碼參考資料： 阮一峰RESTful API設計指南 Roy Thomas Fielding論文地址：Representational State Transfer (REST)
時：2018-04-23