Restful Web Service初識

時間 2020-06-03

標籤 restful web service 欄目 HTML 简体版

原文原文鏈接

1、Web Servicesphp

Web Services 是一種基於組件的軟件平臺，是面向服務的Internet 應用。Web Services 框架的核心技術包括SOAP ,WSDL 和UDDI ,它們都是以標準的XML 文檔的形式表示。html

　　SOAP (「Simple Object Access Protocol」的縮寫)是Web Services 的通訊協議。SOAP是一種簡單的、輕量級的基於XML 的機制，用於在網絡應用程序之間進行結構化數據交換。SOAP包括三部分:一個定義描述消息內容的框架的信封，一組表示應用程序定義的數據類型實例的編碼規則，以及表示遠程過程調用和響應的約定。前端

　　1. 傳遞信息的格式爲XML.這就使Web Services可以在任何平臺上，用任何語言進行實現。mysql

　　2. 遠程對象方法調用的格式。規定了怎樣表示被調用對象以及調用的方法名稱和參數類型等。web

　　3. 參數類型和XML格式之間的映射。這是由於，被調用的方法有時候須要傳遞一個複雜的參數，例如，一個Person對象。怎樣用XML來表示一個對象參數，也是SOAP所定義的範圍。sql

　　WSDL表示WEB服務說明語言。WSDL文件是一個XML 文檔，用於說明一組SOAP消息以及如何交換這些消息。當實現了某種服務的時候(如：股票查詢服務)，爲了讓別的程序調用，必須告訴你們服務接口。例如：服務名稱，服務所在的機器名稱，監聽端口號，傳遞參數的類型，個數和順序，返回結果的類型等等。這樣別的應用程序才能調用該服務。WSDL協議就是規定了有關Web Services描述的標準。數據庫

　　UDDI(「Universal Description， Discovery，and Integration」的縮寫)提供一種發佈和查找服務描述的方法。UDDI 數據實體提供對定義業務和服務信息的支持。WSDL 中定義的服務描述信息是UDDI註冊中心信息的補充。express

Web Services的工做原理以下：json

　　1. Web Services 服務提供方經過WSDL描述所提供的服務，並將這一描述告知Web Services 註冊服務器。後端

　　2. 註冊服務器依據WSDL 的描述，依照UDDI的協定更新服務目錄並在Internet 上發佈。

　　3. 用戶在使用Web Services 前先向註冊服務器發出請求，得到Web Services 提供者的地址和服務接口信息。

　　4. 使用SOAP 協議與Web Services 提供者創建鏈接,進行通訊。

2、REST(Representational State Transfer) Web Services

一般咱們提到Web Services第一想法就是SOAP消息在各類傳輸協議上交互。其實SOAP最先是針對RPC的一種解決方案，簡單對象訪問協議，很輕量，可是隨着 SOAP做爲Web Services的普遍應用，不斷地增長附加的內容，使得如今開發人員以爲SOAP很重，使用門檻很高。在大併發狀況下會有性能問題，在互聯網上使用不太普及，所以並不太適合Web 2.0網站服務使用，目前大量的Web 2.0網站使用另一種解決方案——REST。

　　做爲SOAP模式的替代者，REST(是「Representational State Transfer」的縮寫)是一種輕量級的Web Services架構風格，其實現和操做明顯比SOAP和XML-RPC更爲簡潔，能夠徹底經過HTTP協議實現，還能夠利用緩存Cache來提升響應速度，性能、效率和易用性上都優於SOAP協議。

1. RESTful Web Services是什麼

REST是由Roy Thomas Fielding博士在他的論文《Architectural Styles and the Design of Network-based Software Architectures》中提出的一個術語。REST自己只是爲分佈式超媒體系統設計的一種架構風格，而不是標準。在RESTful系統中，服務器利用URI暴露資源，客戶端使用四個Http謂詞來訪問資源。因爲客戶端接收了資源，他們被置於某種狀態。當他們訪問一個新的資源，一般是點擊下一個鏈接，他們改變了，或者說是過渡了他們的狀態。爲了工做，REST假設資源是可以使用廣泛的標準語法來表明的。

傳統的Web應用大都是B/S架構，它包括了以下一些規範。

　　１.客戶－服務器：這種規範的提出，改善了用戶接口跨多個平臺的可移植性，而且經過簡化服務器組件，改善了系統的可伸縮性。最爲關鍵的是經過分離用戶接口和數據存儲這兩個關注點，使得不一樣用戶終端享受相同數據成爲了可能。

　　2.無狀態性：無狀態性是在客戶－服務器約束的基礎上添加的又一層規範。它要求通訊必須在本質上是無狀態的，即從客戶到服務器的每一個request都必須包含理解該 request所必須的全部信息。這個規範改善了系統的可見性（無狀態性使得客戶端和服務器端沒必要保存對方的詳細信息，服務器只須要處理當前 request，而沒必要了解全部的request歷史），可靠性（無狀態性減小了服務器從局部錯誤中恢復的任務量），可伸縮性（無狀態性使得服務器端能夠很容易的釋放資源，由於服務器端沒必要在多個request中保存狀態）。同時，這種規範的缺點也是顯而易見得，因爲不能將狀態數據保存在服務器上的共享上下文中，所以增長了在一系列request中發送重複數據的開銷，嚴重的下降了效率。

　　3.緩存：爲了改善無狀態性帶來的網絡的低效性，咱們添加了緩存約束。緩存約束容許隱式或顯式地標記一個response中的數據，這樣就賦予了客戶端緩存 response數據的功能，這樣就能夠爲之後的request共用緩存的數據，部分或所有的消除一部分交互，增長了網絡的效率。可是用於客戶端緩存了信息，也就同時增長了客戶端與服務器數據不一致的可能，從而下降了可靠性。

　　B/S架構的優勢是其部署很是方便，但在用戶體驗方面卻不是很理想。爲了改善這種狀況，咱們引入了REST！

　　REST在原有的架構上增長了三個新規範：統一接口、分層系統和按需代碼。

　　１.統一接口：REST架構風格的核心特徵就是強調組件之間有一個統一的接口，這表如今REST世界裏，網絡上全部的事物都被抽象爲資源，而REST就是經過通用的連接器接口對資源進行操做。這樣設計的好處是保證系統提供的服務都是解耦的，極大的簡化了系統，從而改善了系統的交互性和可重用性；而且REST針對Web的常見狀況作了優化，使得REST接口被設計爲能夠高效的轉移大粒度的超媒體數據，這也就致使了REST接口對其它的架構並非最優的。

　　２.分層系統：分層系統規則的加入提升了各類層次之間的獨立性，爲整個系統的複雜性設置了邊界，經過封裝遺留的服務，使新的服務器免受遺留客戶端的影響，這也就提升了系統的可伸縮性。

　　３.按需代碼：REST容許對客戶端功能進行擴展。好比，經過下載並執行applet或腳本形式的代碼，來擴展客戶端功能。但這在改善系統可擴展性的同時，也下降了可見性。因此它只是REST的一個可選的約束。

REST描述了一種設計Web應用的架構風格，它是一組架構約束條件和原則，知足這些約束條件和原則的應用程序或設計就是 RESTful風格的。而符合RESTful風格的Web Services，就是咱們所說的RESTful Web Services。

2. REST原則以下：

REST架構是針對Web應用而設計的，其目的是爲了下降開發的複雜性，提升系統的可伸縮性。

REST中的資源所指的不是數據，而是數據和表現形式的組合，好比「最新訪問的10位會員」和「最活躍的10位會員」在數據上可能有重疊或者徹底相同，而因爲它們的表現形式不一樣，因此被歸爲不一樣的資源，這也就是爲什麼REST的全名是Representational State Transfer的緣由。資源標識符就是URI(Uniform Resource Identifier)，無論是圖片，Word仍是視頻文件，甚至只是一種虛擬的服務，也無論你是xml格式，txt文件格式仍是其它文件格式，所有經過 URI對資源進行惟一的標識。

　　 REST是基於HTTP協議的，任何對資源的操做行爲都是經過HTTP協議來實現。以往的Web開發大多數用的都是HTTP協議中的GET和POST方法，對其餘方法不多使用，這其實是由於對HTTP協議認識片面的理解形成的。HTTP不只僅是一個簡單的運載數據的協議，而是一個具備豐富內涵的網絡軟件的協議。它不只僅能對互聯網資源進行惟必定位，並且還能告訴咱們如何對該資源進行操做。HTTP把對一個資源的操做限制在4個方法之內：GET，POST，PUT和DELETE，這正是對資源CRUD操做的實現。因爲資源和URI是一一對應的，執行這些操做的時候URI是沒有變化的，這和以往的Web開發有很大的區別。正因爲這一點，極大的簡化了Web開發，也使得URI能夠被設計成更爲直觀的反映資源的結構，這種URI的設計被稱做RESTful的URI，這爲開發人員引入了一種新的思惟方式：經過URL來設計系統結構。固然，這種設計方式對一些特定狀況也是不適用的，也就是說不是全部的URI均可以RESTful的。

　　REST之因此能夠提升系統的可伸縮性，就是由於它要求全部的操做都是無狀態的。因爲沒有了上下文(Context)的約束，作分佈式和集羣的時候就更爲簡單，也可讓系統更爲有效的利用緩衝池(Pool），而且因爲服務器端不須要記錄客戶端的一系列訪問，也減輕了服務器端的性能開銷。

REST提出了以下設計準則

資源由URI來指定: 在Web應用中，全部的事物都應該擁有惟一的ID，表明ID的統一律念是：URI。URI構成了一個全局命名空間，使用URI標識你的關鍵資源意味着它們得到了一個惟1、全局的ID。
顯式的使用HTTP方法: REST 要求開發人員顯式地使用 HTTP 方法，而且使用方式與協議定義一致。這個基本 REST 設計原則創建了建立、讀取、更新和刪除（create, read, update, and delete，CRUD）操做與 HTTP 方法之間的一對一映射。根據此映射：
- 若要在服務器上建立資源，應該使用 POST 方法。
- 若要檢索某個資源，應該使用 GET 方法。
- 若要更改資源狀態或對其進行更新，應該使用 PUT 方法。
- 若要刪除某個資源，應該使用 DELETE 方法。

CRUD原則：對於資源只須要四種行爲：Create(建立)、Read(讀取)、 Update(更新)和Delete(刪除)就能夠完成對其操做和處理

除了抽象操做爲基礎的CRUD。全部的接口設計都是針對資源來設計的，也就很相似於咱們的面向對象和麪向過程的設計區別，只不過如今將網絡上的操做實體都做爲資源來看待，同時URI的設計也是體現了對於資源的定位設計

資源多重表述: 針對不一樣的需求提供資源多重表述。這裏所說的多重表述包括XML、JSON、HTML等。即服務器端須要向外部提供多種格式的資源表述，供不一樣的客戶端使用。好比移動應用可使用XML或JSON和服務器端通訊，而瀏覽器則可以理解HTML。
無狀態: 對服務器端的請求應該是無狀態的，完整、獨立的請求不要求服務器在處理請求時檢索任何類型的應用程序上下文或狀態。無狀態約束使服務器的變化對客戶端是不可見的，由於在兩次連續的請求中，客戶端並不依賴於同一臺服務器。一個客戶端從某臺服務器上收到一份包含連接的文檔，當它要作一些處理時，這臺服務器宕掉了，多是硬盤壞掉而被拿去修理，多是軟件須要升級重啓——若是這個客戶端訪問了從這臺服務器接收的連接，它不會察覺到後臺的服務器已經改變了。

　　REST其實並非什麼協議也不是什麼標準，而是將Http協議的設計初衷做了詮釋，在 Http協議被普遍利用的今天，愈來愈多的是將其做爲傳輸協議，而非原先設計者所考慮的應用協議。SOAP消息徹底就是將Http協議做爲消息承載，以致於對於Http協議中的各類參數(例如編碼，錯誤碼等)都置之不顧。

　　舉個例子吧，HTTP GET 請求中的請求 URI 中的查詢字符串包括一組參數，這些參數定義服務器用於查找一組匹配資源的搜索條件。可是在許多狀況下，不優雅的 Web API 使用 HTTP GET 來觸發服務器上的事務性操做——例如，向數據庫添加記錄。如：

　　GET /adduser?name=John HTTP/1.1

　　這不是很是好的設計，由於上面的 Web 方法支持經過 HTTP GET 進行狀態更改操做。Web 服務器旨在經過檢索與請求 URI 中的查詢條件匹配的資源，並在響應中返回這些資源或其表示形式，從而響應 HTTP GET 請求，而不是向數據庫添加記錄。以這種方式使用 GET 是不一致的。

REST不只僅是一種嶄新的架構，它帶來的更是一種全新的Web開發過程當中的思惟方式：經過URL來設計系統結構。在REST中，全部的URL都對應着資源，只要URL的設計是良好的，那麼其呈現的系統結構也就是良好的。這點和 TDD(Test Driven Development)很類似，它是經過測試用例來設計系統的接口，每個測試用例都表示一系列用戶的需求。開發人員不須要一開始就編寫功能，而只須要把須要實現的功能經過測試用例的形式表現出來便可。這個和REST中經過URL設計系統結構的方式相似，咱們只須要根據需求設計出合理地URL，這些 URL不必定非要連接到指定的頁面或者完成一些行爲，只要它們可以直觀的表現出系統的用戶接口。根據這些URL，咱們就能夠方便的設計系統結構。從 REST架構的概念上來看，全部可以被抽象成資源的東西均可以被指定爲一個URL，而開發人員所須要作的工做就是如何能把用戶需求抽象爲資源，以及如何抽象的精確。由於對資源抽象的越爲精確，對REST的應用來講就越好，這個和傳統MVC開發模式中基於Action的思想差異就很是大。設計良好的URL，不但對於開發人員來講能夠更明確的認識系統結構，對使用者來講也方便記憶和識別資源，由於URL足夠簡單和有意義。按照以往的設計模式，不少URL後面都是一堆參數，對於使用者來講也是很不方便的。　　

既然REST這麼好用，那麼是否是全部的Web應用都能採起此種架構呢？答案是否認的。我們知道，直到如今爲止，MVC(Model-View-Controller)模式依然是Web開發最廣泛的模式，絕大多數的公司和開發人員都採起此種架構來開發Web應用，而且其思惟方式也停留於此。MVC模式由數據，視圖和控制器構成，經過事件(Event)觸發Controller來改變Model 和View。加上Webwork,Struts等開源框架的加入，MVC開發模式已經至關成熟，其思想根本就是基於Action來驅動。從開發人員角度上來講，貿然接受一個新的架構會帶來風險，其中的不肯定因素太多，而且REST新的思惟方式是把全部用戶需求抽象爲資源，這在實際開發中是比較難作到的，因爲並非全部的用戶需求都能被抽象爲資源，這樣也就是說不是整個系統的結構都能經過REST的來表現。因此在開發中，咱們須要根據以上2點來在REST和MVC中作出選擇。咱們認爲比較好的辦法是混用REST和MVC，由於這適合絕大多數的Web應用開發，開發人員只須要對比較容易可以抽象爲資源的用戶需求採起REST的開發模式，而對其它需求採起MVC開發便可。這裏須要提到的就是ROR(Ruby on Rails)框架，這是一個基於Ruby語言的愈來愈流行的Web開發框架，它極大的提升了Web開發的速度。更爲重要的是，ROR(從1.2版本起)框架是第一個引入REST作爲核心思想的Web開發框架，它提供了對REST最好的支持，也是當今最成功的應用REST的Web開發框架。實際上，ROR的 REST實現就是REST和MVC混用，開發人員採用ROR框架，能夠更快更好的構建Web應用。

3、RESTful Web Services與基於SOAP的Web Services的比較

基於SOAP的Web Services也是解決異構系統間通訊問題的經常使用方案，那麼，RESTful Web Services相對於基於SOAP 的Web Services，有什麼優點呢？或者說，咱們爲何要開始學習RESTful Web Services，使用已經流行好久的基於SOAP的Web Services不就行了麼？

RESTful Web Services接口更易於使用

RESTful Web Services使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 來抽象全部 Web 系統的服務能力，而不一樣的是，SOAP 應用都經過定義本身個性化的接口方法來抽象 Web 服務。相對來講，RESTful Web Services接口更簡單。

RESTful Web Services使用標準的 HTTP 方法的優點，從大的方面來說：標準化的 HTTP 操做方法，結合其餘的標準化技術，如 URI，HTML，XML 等，將會極大提升系統與系統之間整合的互操做能力。尤爲在 Web 應用領域，RESTful Web Services所表達的這種抽象能力更加貼近 Web 自己的工做方式，也更加天然。

無狀態性

HTTP 協議從本質上說是一種無狀態的協議，客戶端發出的 HTTP 請求之間能夠相互隔離，不存在相互的狀態依賴。基於 HTTP 的 ROA，以很是天然的方式來實現無狀態服務請求處理邏輯。對於分佈式的應用而言，任意給定的兩個服務請求 Request 1 與 Request 2, 因爲它們之間並無相互之間的狀態依賴，就不須要對它們進行相互協做處理，其結果是：Request 1 與 Request 2 能夠在任何的服務器上執行，這樣的應用很容易在服務器端支持負載平衡 (load-balance)。

安全操做與冪指相等特性

HTTP 的 GET、HEAD 請求本質上應該是安全的調用，即：GET、HEAD 調用不會有任何的反作用，不會形成服務器端狀態的改變。對於服務器來講，客戶端對某一 URI 作 n 次的 GET、HAED 調用，其狀態與沒有作調用是同樣的，不會發生任何的改變。

HTTP 的 PUT、DELTE 調用，具備冪指相等特性 , 即：客戶端對某一 URI 作 n 次的 PUT、DELTE 調用，其效果與作一次的調用是同樣的。HTTP 的 GET、HEAD 方法也具備冪指相等特性。

HTTP 這些標準方法在原則上保證你的分佈式系統具備這些特性，以幫助構建更加健壯的分佈式系統。

RESTful Web Services更容易實現緩存

衆所周知，對於基於網絡的分佈式應用，網絡傳輸是一個影響應用性能的重要因素。如何使用緩存來節省網絡傳輸帶來的開銷，這是每個構建分佈式網絡應用的開發人員必須考慮的問題。

HTTP 協議帶條件的 HTTP GET 請求 (Conditional GET) 被設計用來節省客戶端與服務器之間網絡傳輸帶來的開銷，這也給客戶端實現 Cache 機制 ( 包括在客戶端與服務器之間的任何代理 ) 提供了可能。HTTP 協議經過 HTTP HEADER 域：If-Modified-Since/Last- Modified，If-None-Match/ETag 實現帶條件的 GET 請求。

REST 的應用能夠充分地挖掘 HTTP 協議對緩存支持的能力。當客戶端第一次發送 HTTP GET 請求給服務器得到內容後，該內容可能被緩存服務器 (Cache Server) 緩存。當下一次客戶端請求一樣的資源時，緩存能夠直接給出響應，而不須要請求遠程的服務器得到。而這一切對客戶端來講都是透明的。

一些缺陷：

　　先說成熟度，SOAP發展到如今雖然已經背離了初衷，可是對於異構環境服務發佈和調用，以及廠商的支持都已經達到了較爲成熟的狀況。不一樣平臺，開發語言之間經過SOAP來交互的Web Services都可以較好的互通。

　　反觀REST，相比於SOAP的權威性協議規範，REST實現的各類協議只能算是私有協議，固然須要遵循REST的思想，在兼容性方面會差不少。

　　總的來講SOAP在成熟度上優於REST。

　　再說效率，SOAP協議對於消息體和消息頭都有定義，同時消息頭的可擴展性爲各類互聯網的標準提供了擴展的基礎。REST被人們的重視，其實很大緣由是源於其面向資源接口設計以及操做抽象簡化了開發者的不良設計，同時也最大限度的利用了HTTP最初的應用協議設計理念。

　　同時， REST還很好的融合Web2.0的不少前端技術來提升開發效率。例如不少大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml做爲數據承載，還有JSON，RSS，等形式。

　　所以，相對於SOAP， REST的效率更勝一籌。

　　最後說安全性，SOAP在安全方面是經過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實現安全控制的，當前已經獲得了各個廠商的支持。 REST沒有任何規範對於安全方面做說明。

4、案例：爲Web項目構建一個簡單的JSON控制器

在平常應用中，咱們有大量的場合可使用到RESTful Web Services，包括Web系統間的交互，移動客戶端與Web服務器端的通訊等。只有在平常工做中更多的實踐RESTful，才能更好的理解RESTful Web Services。

不管項目使用的是哪一種數據庫後端，JavaScript Object Notation (JSON) 控制器都能簡化開發工做。

假設一個PHP/MySQL 項目：創建一個 MySQL 數據庫，建立包含 HTML 的 PHP 視圖，根據須要添加 JavaScript 代碼和 CSS 文件，鏈接到數據庫，從數據庫提取內容來填充視圖，等等。若是您熟悉 web 開發，您必定知道分隔功能代碼的好處。例如，您知道要避免直接在視圖中輸入原始 SQL 查詢，不會在從數據庫提取數據的函數或類中混淆 HTML 標記。

　　可是，有時，您的項目可能擴展到您的正常 PHP/MySQL 溫馨水平以外。例如，您可能不只擁有須要來自一個數據庫的數據的常規 web 視圖，還擁有外部應用程序（好比 Facebook），甚至還擁有訪問相同數據的移動設備（好比智能手機）。

　　您可能會發現本身身陷這樣一種狀況：數據庫更改，或者要求您處理某種類型的 XML 存儲庫。在這些狀況下，您對 MySQL 的盲目依賴可能會阻礙您完成項目的工做。

　　此時能夠考慮將一個 RESTful JSON 控制器放置到項目中，將它用做一個虛擬交通警察，負責發送請求並接收來自您的數據源的響應。下面將並展現一種創建控制器的方法。其結果是從一個數據源檢索數據的簡單方法，檢索的數據採用標準化的格式，可使用 PHP 或 JavaScript 代碼輕鬆解析。

在一個典型的 REST 架構中，一個客戶機發送一個請求到服務器，服務器使用請求資源的一個表示來進行響應。資源能夠是任何信息對象，好比數據庫或文檔，它的表示一般是一個格式化的文檔（一般是 XML 或 JSON），充當它的當前或被請求狀態的一個快照。
REST 資源一般使用有意義的 URLs 標識，這些 URLs 接受不一樣的請求動詞 GET、POST、PUT 和 DELETE。這些動詞有點相似於許多開發人員都熟悉的 create-retrieve-update-delete (CRUD) 模型。
例如，若是您想檢索數據，則使用 GET 請求；要建立數據，則使用 POST 請求；要更新數據，則使用 PUT 請求；最後，要刪除數據，則使用 DELETE 請求。
另外一個須要考慮的重要因素是響應。RESTful 服務一般在它的響應中提供兩個有意義的組件：響應主體自己和一個狀態碼。許多 REST 服務實際上容許用戶指定一個響應格式（好比 XML、CSV、序列化的 PHP 對象或純文本），方法有兩種：一是發送一個 ACCEPT 參數；二是指定一個文件擴展名（例如，/api/users.xml 或 /api/users.json）。其餘 REST 服務器，好比您將在這裏實現的服務器，擁有硬編碼的響應格式。這些格式一樣能夠接受，只要它們已經有文檔記載。
響應代碼每每是 HTTP 狀態碼。這種模式的優勢是可使用知名的現有狀態碼來標識錯誤或成功。狀態碼 201（CREATED）是一個成功 POST 請求的完美響應。錯誤碼 500 代表在您所處的這端（服務端）上發生了錯誤，但錯誤碼 400 代表客戶端上出現了失敗（BAD REQUEST）。若是服務器出現故障，將發送錯誤碼 503（SERVICE UNAVAILABLE）。

一個應用程序擁有的一個數據源包含一些用戶信息，名、姓、郵件地址、以及Twitter 賬戶。若是您正在設置一個典型的 PHP 應用程序，您須要建立一個 mysql_query() 包裝器來使用一個 SQL 查詢從數據庫提取一個清單。您還須要編寫一些 PHP 代碼，用於調用那個函數並循環結果集，以便在應用程序視圖中顯示數據。

　　設置一個簡單的 REST 控制器，該控制器容許一個針對 /users/list 的、不帶任何參數的 GET 請求，而後調用適當的數據庫函數並返回一個 JSON 格式的清單。接下來，您的應用程序能夠解碼那個 JSON 數據，以任何須要的方式循環該數據，以便顯示數據內容。

　　另外，您能夠經過測試檢查是否有任何參數被髮送到 /users/list。例如，若是您發送一個 GET 請求到 /users/list/1，那麼響應將只包含 ID 爲 1 的用戶的細節。除 JSON 格式外，您甚至能夠容許其餘格式，好比 XML、CSV 和的 PHP 對象。

　　一個 RESTful JSON 控制器對於您的開發工做的做用並不是僅僅是在視圖和數據源之間放置一個額外的功能層。想一想看，您的基本 PHP 視圖也許不是請求信息的唯一組件。例如，您可能會使用 jQuery 經過一個 Ajax 接口請求數據，或者，您的用戶可能會經過一部智能手機或一個 Facebook 應用程序請求數據。

　　在這些狀況下，一個接收請求並以一種容易理解（和預測）的格式提供響應的 RESTful 接口可能會極大地簡化您的開發工做。做爲負責 PHP 視圖（或者甚至 iPhone 應用程序）的開發人員，您能夠發送一些請求到一個 URL 並接收一組預期響應。在 JSON 控制器的另外一面，應用程序能夠被鉤掛（hook）到 MySQL、PostgreSQL、一個 XML 文件存儲庫、或者什麼也不掛。

1. 首先建立一個簡單的事件數據庫架構（MYSQL）

CREATE TABLE `events` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARYKEY ,
`title` VARCHAR( 255 ) NOT NULL ,
`address` VARCHAR( 255 ) NOT NULL ,
`start_time` DATETIME NOT NULL ,
`description` TEXT NOT NULL
);

2. 建立一個典型 PHP 模型文件，它鏈接到這個數據庫並使用一個 SQL 查詢來識別事件。

$SERVER = 'name';
$USER = 'username';
$PASS = 'pw';
$DATABASE = 'dbname';

if (!($mylink = mysql_connect($SERVER, $USER, $PASS)))
{
    echo "Sorry, could not connect to DB. Contact your sysadmin for help!";
    exit;
}
mysql_select_db( $DATABASE );

class Events{
    function get_events($day){
    $ret_array = array();
    $sql ="select id,title,address,start_time,description
    from events where start_time like '$day%'
    order by start_time asc";
    $result = mysql_query($sql);

    while($data = mysql_fetch_object($result)){
    $obj['id'] = $data->id;
    $obj['title'] = $data->title;
$obj['address'] = $data->address;
$obj['start_time'] = $data->start_time;
$obj['description'] = $data->description;

$ret_array[] = $obj;
}
return $ret_array;
}
}

View Code

對這個函數的一個簡單調用時，您將獲得以下所示的結果。

$EVENT = new Events;
$today = '2010-06-17';
$events = $EVENT->get_events($today);
print_r($events);
/* results in
Array
    ([0] => Array(
     [id] => 2
     [title] => Event #2
     [address] => 156 My Avenue, MyTown, USA 78727
     [start_time] => 2010-06-17 11:30:00
     [description] => Join us for lunch to hear
     FABULOUS SPEAKER.
     )
    [1] => Array(
     [id] => 1
     [title] => Event #1
     [address] => 123 My Street, Anytown USA 78727
     [start_time] => 2010-06-17 15:30:00
     [description] => A great event! Hope to see you there!
    )
 )
*/

經過 json_encode() 運行相同的代碼，將獲得一個可移植的 JSON 對象（如所示）

[
　　{"id":"2",
　　"title":"Event #2",
　　"address":"156 My Avenue, MyTown, USA 78727",
　　"start_time":"2010-06-17 11:30:00",
　　"description":"Join us for lunch to hear FABULOUS SPEAKER. "
　　},
　　{"id":"1",
　　"title":"Event #1",
　　"address":"123 My Street, Anytown USA 78727",
　　"start_time":"2010-06-17 15:30:00",
　　"description":"A great event! Hope to see you there!"
　　}
]

目標是構建這樣一個簡單的控制器：它知道應該運行哪一個模型和函數，而後返回一個 JSON 對象做爲響應，這個響應可用於事務的遠端。這個控制器很是簡單，看起來以下所示。將以下全部代碼粘貼到一個名爲 json.php 的文件中。

class JSON{
    var $response = '';
    function JSON($model,$function,$params){
        $REQUEST = new $model;
        $data = $REQUEST->$function($params);
        $this->response = json_encode($data);
    }
}

調用的模型，實例化 JSON 類，而後傳入 3 個參數：模型的類名、要運行的函數、以及該函數的參數。這個類而後調用那個函數並獲取一個響應，該響應經過 json_encode() 運行。　　

3. 最後一步是建立包含對 JSON 數據的請求的文件。這個特殊的文件（您能夠稱之爲 listing.php）能夠設置爲接收 3 個 GET 變量（模型、函數和參數各一個），而後將這些變量傳遞給 JSON 類（如清單 7 所示）

請求代碼

//this is the code that contains the model
require 'events.php';
//this is the JSON controller
require 'json.php';
//pass in your three GET parameters
$MODEL = $_GET['model'];
$FUNCTION = $_GET['function'];
//check to see if param is passed in
//if not, use today's date in this instance
if (isset($_GET['param'])){
    $PARAM = $_GET['param'];
}else{
    $PARAM = date("Y-m-d");
}
//invoke
$JSON = new JSON($MODEL,$FUNCTION,$PARAM);
//access the response variable
echo $JSON->response;

能夠將這個文件加載到一個瀏覽器中，並獲取一個 JSON 對象。再經過 json_decode() 將這個 JSON 對象發送回去，使用 JavaScript 代碼處理它，或者讓它保持原樣。

　　整個這個流程的一個甚至更好的方法是建立一個更緊密模擬 RESTful 服務器的路徑結構。例如，能夠建立一個名爲 events/today 的目錄結構，該結構包含一個名爲 index.php 的文件。經過將您的瀏覽器指向 /events/today，無需傳入任何 GET 變量，您就能夠基於以下的代碼取回一個 JSON feed。
/events/today/index.php 中的代碼

require '../../events.php';
require '../../json.php';
$MODEL ="Events";
$FUNCTION ="get_events";
$PARAM = date("Y-m-d");
//invoke
$JSON =new JSON($MODEL,$FUNCTION,$PARAM);
echo $JSON->response;
//prints out
[
    {"id":"3",
     "title":"Test Event 3",
     "address":"111 Main Street, Austin TX 78727",
     "start_time":"2010-06-10 15:15:00",
     "description":"Testing 456."
    }
]