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."
    }
]

使用这种方法，您能够为您的视图和支持的应用程序简化一些数据提取要求。开发人员无需记住底层数据库的全部细节，相反，他们能够轻松命中 URLs 并接收他们寻找的响应来继续他们的工做。

参考：

http://tech.it168.com/a2012/0919/1400/000001400252.shtml
http://express.ruanko.com/ruanko-express_37/technologyexchange6.html
http://nepoulia.blog.51cto.com/2722590/579151
10 个技巧让你的 RESTful Web 服务更加实用
为您的Web项目构建一个简单的JSON控制器
在CodeIgniter框架中使用RESTful服务
浅谈REST