PHP教程 第5页

框架里面常用到类调用驱动类，如DB类调用MySQL类，MySQLi类，MSSQL类等。

今天记录一个简单点的LOG类（日志）调用File类（文件模式），Mysql类（mysql存储）

log.php

<?php
namespace mbphp\lib\drive\log;
use mbphp\lib\conf;
class file{

    public $path;//日志存储路径
    public function __construct()
    {
        $option = conf::get('option','log');
        $this->path = $option['path'];
    }

    /**
     * 写日志
     * @param $msg
     * @param string $file
     */
    public function log($msg,$file='log'){
        //检测目录是否存在
        if(!is_dir($this->path)){
            //新建目录
            mkdir($this->path,'0777',true);
        }

        //写入日志
        $data = '['.date('Y-m-d H:i:s').']  '.json_encode($msg).PHP_EOL;
        $path = $this->path.'/'.$file.'_'.date('Ymd').'.log';
        $rs = file_put_contents($path,$data,FILE_APPEND);
        return $rs;
    }
}

log/file.php

<?php
namespace mbphp\lib\drive\log;
use mbphp\lib\conf;
class file{

    public $path;//日志存储路径
    public function __construct()
    {
        $option = conf::get('option','log');
        $this->path = $option['path'];
    }

    /**
     * 写日志
     * @param $msg
     * @param string $file
     */
    public function log($msg,$file='log'){
        //检测目录是否存在
        if(!is_dir($this->path)){
            //新建目录
            mkdir($this->path,'0777',true);
        }

        //写入日志
        $data = '['.date('Y-m-d H:i:s').']  '.json_encode($msg).PHP_EOL;
        $path = $this->path.'/'.$file.'_'.date('Ymd').'.log';
        $rs = file_put_contents($path,$data,FILE_APPEND);
        return $rs;
    }
}

注：代码是自己写的框架中copy出来的，设计到其他类与配置文件，参考思路。不要copy不改配置就运行，运行不起的(*^__^*) 嘻嘻

运行环境：

PHPSTORM版本 : 8.0.1

PHP版本 : 5.6.2

xdebug版本：php_xdebug-2.2.5-5.6-vc11-x86_64.dll

ps : php版本和xdebug版本一定要相对应

点击下载Xdebug

1. PHP安装xdebug扩展

php.ini的配置，下面的配置仅供参考，路径要换成自己的！

[xdebug]
zend_extension="D:\wamp\php-5.6.2-x64\ext\php_xdebug-2.2.5-5.6-vc11-x86_64.dll"
xdebug.remote_enable = On
xdebug.remote_handler = dbgp
xdebug.remote_host= localhost
xdebug.remote_port = 9000
xdebug.idekey = PHPSTORM

ps : remote_handler 、remote_host、remote_port 这些都有默认值，但还是建议设置下，至少知道要设置这些参数~

查看phpinfo~

【或者使用PHPstudy：其他选项菜单/PHP扩展设置/PHP扩展/XDEBUG打上对钩】

2.PHPSTORM设置

楼主以前一直用zendstudio，刚开始用phpstorm非常蛋疼，用了一段时间后发现还挺好用的~

1.首先检查phpstorm的xdebug配置

这里的debug port要和php.ini里面的xdebug.remote_port相一致！默认是9000，如果9000端口被占用的话，可以改成其他端口。

2. 设置debug.

添加本地的 web server~

www.mall.com是我本地的服务

3.开始调试

1. 打好第一个断点，shift + F9就可以了
2. 打好第一个断点，选中配置的debug,  按旁边的臭虫 按钮

或者还是看不懂，好吧，那请看下面链接：

http://wenku.baidu.com/link?url=osFXlDZtbYW2yOxJYwKukXButWW647d2d87-d69F56FmbU1Wi7YNK-KCGcrL-car-o1U_r2Y0xkXnqoZw2I87FsKdMb7Z9N9pZZvB1a8Lrq

常见问题：

Debug session was finished without being paused
It may be caused by path mappings misconfiguration or not synchronized local and remote projects.
To figure out the problem check path mappings configuration for 'www.test.com' server at PHP|Servers or enable Break at first line in PHP scripts option (from Run menu).

 没有打断点或者调试没有被监测到，碰到这个问题，看看路径配置对了吗是否能访问到

安装

开始在 PHP 中使用 Redis 前， 我们需要确保已经安装了 redis 服务及 PHP redis 驱动，且你的机器上能正常使用 PHP。 接下来让我们安装 PHP redis 驱动：下载地址为:https://github.com/phpredis/phpredis/releases。

PHP安装redis扩展

以下操作需要在下载的 phpredis 目录中完成：

$ wget https://github.com/phpredis/phpredis/archive/2.2.4.tar.gz
$ cd phpredis-2.2.7                      # 进入 phpredis 目录
$ /usr/local/php/bin/phpize              # php安装后的路径
$ ./configure --with-php-config=/usr/local/php/bin/php-config
$ make && make install

如果你是 PHP7 版本，则需要下载指定分支：

git clone -b php7 https://github.com/phpredis/phpredis.git

修改php.ini文件

vi /usr/local/php/lib/php.ini

增加如下内容:

extension_dir = "/usr/local/php/lib/php/extensions/no-debug-zts-20090626"

extension=redis.so

安装完成后重启php-fpm 或 apache。查看phpinfo信息，就能看到redis扩展。

连接到 redis 服务

<?php
    //连接本地的 Redis 服务
   $redis = new Redis();
   $redis->connect('127.0.0.1', 6379);
   echo "Connection to server sucessfully";
         //查看服务是否运行
   echo "Server is running: " . $redis->ping();
?>

执行脚本，输出结果为：

Connection to server sucessfully
Server is running: PONG

Redis PHP String(字符串) 实例

<?php
   //连接本地的 Redis 服务
   $redis = new Redis();
   $redis->connect('127.0.0.1', 6379);
   echo "Connection to server sucessfully";
   //设置 redis 字符串数据
   $redis->set("tutorial-name", "Redis tutorial");
   // 获取存储的数据并输出
   echo "Stored string in redis:: " . $redis->get("tutorial-name");
?>

执行脚本，输出结果为：

Connection to server sucessfully
Stored string in redis:: Redis tutorial

Redis PHP List(列表) 实例

<?php
   //连接本地的 Redis 服务
   $redis = new Redis();
   $redis->connect('127.0.0.1', 6379);
   echo "Connection to server sucessfully";
   //存储数据到列表中
   $redis->lpush("tutorial-list", "Redis");
   $redis->lpush("tutorial-list", "Mongodb");
   $redis->lpush("tutorial-list", "Mysql");
   // 获取存储的数据并输出
   $arList = $redis->lrange("tutorial-list", 0 ,5);
   echo "Stored string in redis";
   print_r($arList);
?>

执行脚本，输出结果为：

Connection to server sucessfully
Stored string in redis
Redis
Mongodb
Mysql

Redis PHP Keys 实例

<?php
   //连接本地的 Redis 服务
   $redis = new Redis();
   $redis->connect('127.0.0.1', 6379);
   echo "Connection to server sucessfully";
   // 获取数据并输出
   $arList = $redis->keys("*");
   echo "Stored keys in redis:: ";
   print_r($arList);
?>

执行脚本，输出结果为：

Connection to server sucessfully
Stored string in redis::
tutorial-name
tutorial-list

Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度。Memcached基于一个存储键/值对的hashmap。其守护进程（daemon ）是用C写的，但是客户端可以用任何语言来编写

memcached是什么?

memcached 是一个高性能的分布式内存对象缓存系统，用于动态web应用以减轻数据库教程负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度。memcached基于一个存储键/值对的hashmap。其守护进程（daemon ）是用c写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。但是它并不提供冗余（例如，复制其hashmap条目）；当某个服务器s停止运行或崩溃了，所有存放在s上的键/值对都将丢失。 　　memcached由danga interactive开发，用于提升livejournal.com访问速度的。lj每秒动态页面访问量几千次，用户700万。memcached将数据库负载大幅度降低，更好的分配资源，更快速访问。

memcache常用方法

memcache::add — 添加一个值，如果已经存在，则返回false
memcache::addserver — 添加一个可供使用的服务器地址
memcache::close — 关闭一个memcache对象
memcache::connect — 创建一个memcache对象
memcache::debug — 控制调试功能
memcache::decrement — 对保存的某个key中的值进行减法操作
memcache::delete — 删除一个key值
memcache::flush — 清除所有缓存的数据
memcache::get — 获取一个key值
memcache::getextendedstats — 获取进程池中所有进程的运行系统统计
memcache::getserverstatus — 获取运行服务器的参数
memcache::getstats — 返回服务器的一些运行统计信息
memcache::getversion — 返回运行的memcache的版本信息
memcache::increment — 对保存的某个key中的值进行加法操作
memcache::pconnect — 创建一个memcache的持久连接对象
memcache::replace — r对一个已有的key进行覆写操作
memcache::set — 添加一个值，如果已经存在，则覆写
memcache::setcompressthreshold — 对大于某一大小的数据进行压缩
memcache::setserverparams — 在运行时修改服务器的参数

memcache方法使用

代码如下:

<?php
$memcache = new memcache;
$memcache->connect('127.0.0.1', 11211) or die("连接失败");
$memcache->set('name', '张三');
$val = $memcache->get('name');
?>

注:set方法的完整版本,set(键名,键值,是否压缩，保持时间)

代码如下:

<?php
$memcache = new memcache;
$memcache -> connect('127.0.0.1', 11211) or die("连接失败");
$memcache -> set('name', array('一个','两个'));
$val = $memcache->get('name');
print_r($val);
$memcache -> close();
?>

str_replace() 函数

定义：使用一个字符串替换字符串中的另一些字符,对大小写敏感的搜索
语法：

str_replace(find,replace,string,count)

 

str_ireplace() 函数
定义:使用一个字符串替换字符串中的另一些字符,对大小写不敏感的搜索
语法：str_ireplace(find,replace,string,count)

str_replace详解
在都不使用数组时，该函数直接使用replace替换所有的search并返回替换后的字符串。如：str_replace(“m”,”n”,”my name is jim!”)返回ny nane is jin!

1、只对search使用数组。
示例：str_replace(array(‘m’,’i’),’n’,”my name is jim!”);返回：ny nane ns jnn!
可以看出，函数顺序性的对数组中每个字符串进行替换，并返回替换后的字符串。

2、只对replace使用数组。
示例：str_replace(‘m’,array(‘n’,’z’),”my name is jim!n”)返回：Arrayy naArraye is jiArray!
该替换比较有意思，如果只对第二个参数使用数组则函数将其作为字符串Array进行使用，将所有的search替换为了数组。

3、只对subject使用数组。

示例：str_replace(“m”,”n”,array(“my name is jim!”,”the game is over!”))该语句执行结果返回一个数组，即分别为传入的两个字符串替换后的结果。
如果输出数组内容会看到：ny nane is jin! the gane is over!

4、对search和replace都使用数组。

示例：str_replace(array(“m”,”i”),array(“n”,”z”),”my name is jim!”)返回：ny nane zs jzn!
查看执行结果可以发现，如果前两个参数都使用数组则函数把数组各个对象项字符串进行了替换，及search的第一项替换为replace的第一项。以此类推。
如果search数组比new_deedle长，例如：str_replace(array(“m”,”i”,”s”),array(“n”,”z”), “my name is jim!”);返回：ny nane z jzn!可见，对于search数组多出来的字符串被替换为了空串。
如果replace数组比search长，例如：str_replace(array(“m”,”i”),array(“n”,”z”,”x”), “my name is jim!”)返回ny nane zs jzn!可见replace多余的项被忽略。

5、三个参数都使用数组。

例如：str_replace(array(“m”,”i”),array(“n”,”z”),array(“my name is jim!”,”the game is over”))返回的数组内容：ny nane zs jzn!the gane zs over
这个比较好理解，对两个字符串分别执行替换。

例子

<?php
$find = array("Hello","world");
$replace = array("B");
$arr = array("Hello","world","!");
print_r(str_ireplace($find,$replace,$arr));
?>

输出：

Array
(
[0] => B
[1] =>　　　//注意这个地方为什么为空呢。。是因为三个数组是一一对应的，如果数组不一致，不足的则以空补齐
[2] => !
)

一、ORM简介
对象关系映射（Object Relational Mapping，简称ORM）模式是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。那么，到底如何实现持久化呢？一种简单的方案是采用硬编码方式，为每一种可能的数据库访问操作提供单独的方法。
这种方案存在以下不足：
1.持久化层缺乏弹性。一旦出现业务需求的变更，就必须修改持久化层的接口
2.持久化层同时与域模型与关系数据库模型绑定，不管域模型还是关系数据库模型发生变化，毒药修改持久化曾的相关程序代码，增加了软件的维护难度。

ORM提供了实现持久化层的另一种模式，它采用映射元数据来描述对象关系的映射，使得ORM中间件能在任何一个应用的业务逻辑层和数据库层之间充当桥梁。Java典型的ORM中间件有:Hibernate,ibatis,speedframework。
ORM的方法论基于三个核心原则：
· 简单：以最基本的形式建模数据。
· 传达性：数据库结构被任何人都能理解的语言文档化。
· 精确性：基于数据模型创建正确标准化了的结构。

二、ORM的概念
让我们从O/R开始。字母O起源于”对象”(Object),而R则来自于”关系”(Relational)。几乎所有的程序里面，都存在对象和关系数据库。在业务逻辑层和用户界面层中，我们是面向对象的。当对象信息发生变化的时候，我们需要把对象的信息保存在关系数据库中。
当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码，用来从数据库保存，删除，读取对象信息，等等。你在DAL中写了很多的方法来读取对象数据，改变状态对象等等任务。而这些代码写起来总是重复的。

ORM解决的主要问题是对象关系的映射。域模型和关系模型分别是建立在概念模型的基础上的。域模型是面向对象的，而关系模型是面向关系的。一般情况下，一个持久化类和一个表对应，类的每个实例对应表中的一条记录，类的每个属性对应表的每个字段。
ORM技术特点：
1.提高了开发效率。由于ORM可以自动对Entity对象与数据库中的Table进行字段与属性的映射，所以我们实际可能已经不需要一个专用的、庞大的数据访问层。
2.ORM提供了对数据库的映射，不用sql直接编码，能够像操作对象一样从数据库获取数据。

三、ORM的优缺点
ORM的缺点是会牺牲程序的执行效率和会固定思维模式。
从系统结构上来看,采用ORM的系统一般都是多层系统，系统的层次多了，效率就会降低。ORM是一种完全的面向对象的做法，而面向对象的做法也会对性能产生一定的影响。

在我们开发系统时，一般都有性能问题。性能问题主要产生在算法不正确和与数据库不正确的使用上。ORM所生成的代码一般不太可能写出很高效的算法，在数据库应用上更有可能会被误用，主要体现在对持久对象的提取和和数据的加工处理上，如果用上了ORM,程序员很有可能将全部的数据提取到内存对象中，然后再进行过滤和加工处理，这样就容易产生性能问题。
在对对象做持久化时，ORM一般会持久化所有的属性，有时，这是不希望的。
但ORM是一种工具，工具确实能解决一些重复，简单的劳动。这是不可否认的。但我们不能指望工具能一劳永逸的解决所有问题，有些问题还是需要特殊处理的，但需要特殊处理的部分对绝大多数的系统，应该是很少的。

首先说说我对现在主流的ORM框架的一些看法：

优点：

1. 让程序员不再关注数据库细节，专心在业务逻辑上，程序员可以不懂数据库就可以开发系统。
2. 让数据库迁移变的非常方便，如果系统需要更改使用的数据库，直接改配制就好了，不要再管不同数据库之间的语法差异。
3. 省时，可快速开发，因为不需要自己写复杂的SQL语句，不需要封装复杂的数据底层，这样可以节省很多时间。

缺点：

1. 我觉得不懂数据库的程序员不是好程序员，ORM不能帮你生成所有的业务语句，有些复杂的生成不了，还是需要写SQL，例如复杂的报表。
2. 配制过于繁琐，出错后不好定位问题点在哪。
3. 性能低，因为它内部是使用了大量反射，还有数据库检测，造成性能必然低下。
4. 需要额外的学习成本，虽然不需要学习数据库，但是需要学习ORM语句。
5. 容易引起不规范开发，因为ORM可以在任何地方写ORM语句然后调用开发，这样对于初始程序员来说他们很可能在系统的任何地方乱丢ORM语句，这样给维护带来了很大的难度。

因为我一直都不看好这些ORM框架所以缺点写多了点，可能还有些优点是我不知道的，路过的人要是知道可以给我留言，我再补上。

1. 安装

两种安装方式，我热衷于以chrome插件形式安装
Chrome插件
Mac App

2. 发送请求

Postman最基础的功能就是发送http请求，支持GET/PUT/POST/DELETE，还有很多我不认识的http方法。

通过填写URL、header、body等就可以发送一个请求，这对于我们平时做一些简单的测试是够用的。

如果你的应用需要用到登录验证，可以通过填写Authorization以满足你的需求。
另外也可以使用Chrome浏览器已经登录的cookie，同步浏览器的cookie需要安装另一个插件Interceptor（拦截机）。它可以在你发送请求时帮你将已经存在于浏览器的数据随header请求，另外它可以将浏览器的请求写到postman的历史中（需要开启“Request Capture”
）。

3. 集合

每次配置完一个请求都可以保存到一个集合中，如此一来，下次测试可以直接从集合中找到你要执行的测试。

集合不单单只有分类和存储功能，Postman支持一键运行整个集合内的测试。

我们可以把一个请求当做一个Test Case, 那么集合就是一个Test Suite。

每个集合都对应一个URL，可以通过Share按钮获得你的集合URL，这个URL可以用于分享给你的队友，或者用于Newman执行。

Newman是Postman的一个命令行工具，可以让API测试加入到你的持续集成任务上。

4. 环境变量

当做API测试时，你可能经常需要切换不同的设置。比如，开发环境的API设置、测试环境和产品环境的API设置，你可能需要在不同的测试环境下使用不同的配置。为此Postman提供了环境变量，这样你就可以通过修改环境变量，而不需修改请求了。

你可以通过右上角的下拉菜单选择环境，可以通过点击右侧的小眼睛来查看当前环境变量。

5. API测试

Postman测试沙箱是一个JavaScript执行环境，可以通过JS脚本来编写pre-requist和测试脚本。pre-requist可以用来修改一些默认参数。

Postman沙箱集成了几个工具库，比如lodash、SugarJs、tv4，还有一些内置函数如xml2JSON..

tv4用于验证JSON数据，通过编写JSON Schema来验证，JSON Schema的语法请参照这里

测试语法：

// description 为该测试的描述
// value 只要Boolean(value)不等于false，这个测试就是PASS
tests[description] = value

// example
tests["Status code is 200"] = responseCode.code === 200;

我们以github status的接口为例：
url: https://status.github.com/api/status.json

tests["Status code is 200"] = responseCode.code === 200;

// validate json schema
var schema = {
  properties: {
      status: {type: 'string'},
      last_updated: {type: 'string'}
  }
};

tests["Valid data schema"] = tv4.validate(responseBody, schema);

// check status
var jsonData = JSON.parse(responseBody);
tests["Github status is good"] = jsonData.status === 'good';

运行结果：

示例

受 http://httpbin.org/ 启发，Postman也提供了一套入门的API http://dump.getpostman.com/ ，接下来我们将利用这套API做完整的测试。

1. 创建一个环境变量

点击Manage Environments，然后点击Add

添加一个URL变量，我们会在后续使用

2. 请求一个新用户

我们需要通过发送一个POST请求到{{url}}/blog/users/来创建一个用户，并需要附加下面的参数到请求body中：

注：记得将环境变量切换到dump.getpostman.com，这样我们才能获取到{{url}}变量

{
  "username": "abhinav",
  "password": "abc"
}

这个接口现在好像不支持创建用户了，我们假设已经创建成功了，因为这不影响我们后续操作

3. 获取用户的Token

Token用于授予终端请求和访问权限的。我们可以通过POST用户名和密码请求 {{url}}/blog/users/tokens/ 来获取用户的Token，这个Token将用于其他请求中。

{
  "username": "abhinav",
  "password": "abc"
}

4. 格式化JSON

我们需要从上面的请求结果中获取到用户Token和用户ID，并将这两个值保存到环境变量中，以供后续使用。将下面这段代码添加到测试编辑器中：

var data = JSON.parse(responseBody);

if (data.token) {
  tests["Body has token"] = true;
  postman.setEnvironmentVariable("user_id", data.user_id);
  postman.setEnvironmentVariable("token", data.token);
}
else {
  tests["Body has token"] = false;
}

5. 创建一篇文章

如果上面的测试是在主窗口或者集合运行器中执行，那么 user_id 和 token 会自动地被添加到环境变量中。
为了创建一篇文章，我们需要发送一个POST请求到 {{url}}/blog/posts ，并将 user_id 和 token 添加在URL参数中。POST的请求Body如下：

{
  "post": "This is a new post"
}

6. 检查返回数据

如果上述的请求成功的话将返回一个带有post_id的JSON。我们将在这里验证是否创建文章成功，并且将文章ID保存到环境变量。将下面这段代码添加到测试编辑器中：

var data = JSON.parse(responseBody);
 
if (data.post_id) {
  tests["post_id found"] = true;
 
  postman.setEnvironmentVariable("post_id", data.post_id);
}
else {
  tests["post_id found"] = false;
}

7. 获取一篇文章并验证JSON

我们将通过上面返回的文章ID来获取我们创建的文章。这里我们将用到Postman内置的 tv4 JSON 验证器来检查服务器响应的JSON。
创建一个GET请求到 {{url}}/blog/posts/{{post_id}}，并将下面这段代码添加到测试编辑器中：

var schema = {
  "type": "object",
  "properties": {
    "content": "string",
    "created_at": "integer",
    "id": "integer"
  },
  "required": ["content", "created_at", "id"]
};
 
var data = JSON.parse(responseBody);
 
var result = tv4.validateResult(data, schema);
 
tests["Valid schema"] = result.valid; 

8. 一键运行与分享集合

我们将上述每一个测试保存到PostmanTest的集合中，这样我们就可以在任何时候打开和运行你想要的测试，并且可以一键运行所有，或者将集合分享给你的小伙伴，也可以获取嵌入式代码（如下面的按钮）。

本文的所有测试用例都在这里

在RESTful Api开发中，使用Http用来返回错误和状态是非常常用和友好的，其中常用的状态
码有以下这些（rest只是风格，目前没有状态码的标准，下面都是大家常用的状态码，更多的自己和前端（app）协商）。

200 – OK – 一切正常
201 – OK – 新资源已经被创建
204 – OK – 资源删除成功

304 – 没有变化，客户端可以使用缓存数据

400 – Bad Request – 调用不合法，确切的错误应该在error payload中描述，例如：“JSON 不合法 ”
401 – 未认证，调用需要用户通过认证
403 – 不允许的，服务端正常解析和请求，但是调用被回绝或者不被允许
404 – 未找到，指定的资源不存在
422 – 不可指定的请求体 – 只有服务器不能处理实体时使用，比如图像不能被格式化，或者重要字段丢失。

500 – Internal Server Error – 标准服务端错误，API开发人员应该尽量避开这种错误

学习RESTFul Api的最佳方式就是找到前(can)车(kao)之(dui)鉴(xiang),俗称模仿。

国内非常好的（豆瓣API）：https://developers.douban.com/wiki/

国外非常好的（GitHub）：https://developer.github.com/

千万注意：RESTFul Api合理使用，千万不要照搬标准REST。

由于第一次接触WebService，对于很多概念不太理解，尤其是看到各个OpenAPI的不同提供方式时，更加疑惑。如google map api采用了AJAX方式，通过javascript提供API,而淘宝TOP则采用直接的HTTP+XML请求方式，最令我疑惑的是教材上讲的WSDL，UDDI从没有在这些API中出现过。现在知道了WebService原来有两种方式，一是SOAP协议方式，在这种方式下需要WSDL,UDDI等，二是REST方式，这种方式根本不需要WSDL,UDDI等。而且REST方式现在看来是更加流行，更有前途的方式。
在SOA的基础技术实现方式中WebService占据了很重要的地位，通常我们提到WebService第一想法就是SOAP消息在各种传输协议上交互。近几年REST的思想伴随着SOA逐渐被大家接受，同时各大网站不断开放API提供给开发者，也激起了REST风格WebService的热潮。
在收到新需求Email之前，我对REST的理解仅仅是通过半懂不懂的看了Fielding的REST博士论文，说实话当时也就是希望了解这么一个新概念，对于其内部的思想只是很肤浅的了解了一下。
ASF的最新需求就是可能需要实现REST风格的WebService集成，因此不得不好好的去看看REST的真正思想含义以及当前各大网站的设计方式。后面所要表述的也是我这个初学者的一些看法和观点，抛砖引玉，希望在我将REST融入到ASF之前能够获得更多的反馈和意见。

SOAP
什么是SOAP，我想不用多说，google一把满眼都是。其实SOAP最早是针对RPC的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。

REST
REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子，SOAP消息完全就是将Http协议作为消息承载，以至于对于Http协议中的各种参数（例如编码，错误码等）都置之不顾。其实，最轻量级的应用协议就是Http协议。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。
自己理解的将REST的思想归结以下有如下几个关键点：

1．面向资源的接口设计
所有的接口设计都是针对资源来设计的，也就很类似于我们的面向对象和面向过程的设计区别，只不过现在将网络上的操作实体都作为资源来看待，同时URI的设计也是体现了对于资源的定位设计。后面会提到有一些网站的API设计说是REST设计，其实是RPC-REST的混合体，并非是REST的思想。

2．抽象操作为基础的CRUD
这点很简单，Http中的get,put,post,delete分别对应了read,update,create,delete四种操作，如果仅仅是作为对于资源的操作，抽象成为这四种已经足够了，但是对于现在的一些复杂的业务服务接口设计，可能这样的抽象未必能够满足。其实这也在后面的几个网站的API设计中暴露了这样的问题，如果要完全按照REST的思想来设计，那么适用的环境将会有限制，而非放之四海皆准的。

3．Http是应用协议而非传输协议
这点在后面各大网站的API分析中有很明显的体现，其实有些网站已经走到了SOAP的老路上，说是REST的理念设计，其实是作了一套私有的SOAP协议，因此称之为REST风格的自定义SOAP协议。

4．无状态，自包含
这点其实不仅仅是对于REST来说的，作为接口设计都需要能够做到这点，也是作为可扩展和高效性的最基本的保证，就算是使用SOAP的WebService也是一样。

REST vs SOAP
成熟度：
SOAP虽然发展到现在已经脱离了初衷，但是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的情况。不同平台，开发语言之间通过SOAP来交互的web service都能够较好的互通（在部分复杂和特殊的参数和返回对象解析上，协议没有作很细致的规定，导致还是需要作部分修正）
REST国外很多大网站都发布了自己的开发API，很多都提供了SOAP和REST两种Web Service，根据调查部分网站的REST风格的使用情况要高于SOAP。但是由于REST只是一种基于Http协议实现资源操作的思想，因此各个网站的REST实现都自有一套，在后面会讲诉各个大网站的REST API的风格。也正是因为这种各自实现的情况，在性能和可用性上会大大高于SOAP发布的web service，但统一通用方面远远不及SOAP。由于这些大网站的SP往往专注于此网站的API开发，因此通用性要求不高。
ASF上考虑发布REST风格的Web Service，可以参考几大网站的设计（兄弟公司的方案就是参考了类似于flickr的设计模式），但是由于没有类似于SOAP的权威性协议作为规范，REST实现的各种协议仅仅只能算是私有协议，当然需要遵循REST的思想，但是这样细节方面有太多没有约束的地方。REST日后的发展所走向规范也会直接影响到这部分的设计是否能够有很好的生命力。
总的来说SOAP在成熟度上优于REST。

效率和易用性：
SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各种互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。
REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。
因此在效率和易用性上来说，REST更胜一筹。

安全性：
这点其实可以放入到成熟度中，不过在当前的互联网应用和平台开发设计过程中，安全已经被提到了很高的高度，特别是作为外部接口给第三方调用，安全性可能会高过业务逻辑本身。
SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持（虽然在一些细节上还是有不兼容的问题，但是互通基本上是可以的）。
REST没有任何规范对于安全方面作说明，同时现在开放REST风格API的网站主要分成两种，一种是自定义了安全信息封装在消息中（其实这和SOAP没有什么区别），另外一种就是靠硬件SSL来保障,但是这只能够保证点到点的安全，如果是需要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题，今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO，其实是直接采用了XML-Security和XML-Signature，效率看起来也不是很高。未来REST规范化和通用化过程中的安全是否也会采用这两种规范，是未知的，但是加入的越多，REST失去它高效性的优势越多。

应用设计与改造：
我们的系统要么就是已经有了那些需要被发布出去的服务，要么就是刚刚设计好的服务，但是开发人员的传统设计思想让REST的形式被接受还需要一点时间。同时在资源型数据服务接口设计上来说按照REST的思想来设计相对来说要容易一些，而对于一些复杂的服务接口来说，可能强要去按照REST的风格来设计会有些牵强。这一点其实可以看看各大网站的接口就可以知道，很多网站还要传入function的名称作为参数，这就明显已经违背了REST本身的设计思路。
而SOAP本身就是面向RPC来设计的，开发人员十分容易接受，所以不存在什么适应的过程。

总的来说，其实还是一个老观念，适合的才是最好的
技术没有好坏，只有是不是合适，一种好的技术和思想被误用了，那么就会得到反效果。REST和SOAP各自都有自己的优点，同时如果在一些场景下如果去改造REST，其实就会走向SOAP（例如安全）。
REST对于资源型服务接口来说很合适，同时特别适合对于效率要求很高，但是对于安全要求不高的场景。而SOAP的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景。
同时很重要一点就是不要扭曲了REST现在很多网站都跟风去开发REST风格的接口，其实都是在学其形，不知其心，最后弄得不伦不类，性能上不去，安全又保证不了，徒有一个看似象摸象样的皮囊。

REST设计的几种形式
参看了几个大型网站的REST风格的API设计，这里做一下大致的说明：

FaceBook:

请求消息：
在URI设计上采取了类似于REST的风格。例如对于friends的获取，就定义为friends.get，前面部分作为资源定义，后面是具体的操作，其他的API也是类似，资源+操作，因此就算使用http的get方法都可能作了update的操作，其实已经违背了REST的思想，但是说到，其实那么复杂的业务接口设计下，要通过RUCD来抽象所有的接口基本是不实际的。在URI定义好以后，还有详细的参数定义，包括类型以及是否必选。

响应消息：
有多种方式，XML,JSON。XML有XSD作为参考。有点类似于没有Head的SOAP，只不过这里将原来可以定义在WSDL中的XSD抽取出来了。

Flickr:
请求消息：
http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value
这里就可以很明显看出它所定制的REST请求其实和RPC没有什么太大的区别。

消息返回：
正确处理返回
<?xml version=”1.0″ encoding=”utf-8″ ?>
<rsp stat=”ok”>
[xml-payload-here]
</rsp>
错误处理返回
<?xml version=”1.0″ encoding=”utf-8″ ?>
<rsp stat=”fail”>
<err code=”[error-code]” msg=”[error-message]” />
</rsp>
根据返回可以看出已经违背了REST的思想，还是把Http协议作为传输承载协议，并没有真正意义上使用Http协议作为资源访问和操作协议。
总的来说，只是形式上去模仿REST，自己搞了一套私有协议。

Ebay：
请求消息：
采用xml作为承载，类似于SOAP，不过去除SOAP消息的封装和包头，同时在请求中附加了认证和警告级别等附加信息。
消息返回：
类似于SOAP消息，不过删除了SOAP的封装和包头，同时在返回结构中增加了消息处理结果以及版本等附加信息。
这个很类似于当前Axis2框架的做法，将SOAP精简，同时根据自身需求丰富了安全，事务等协议内容。

Yahoo Maps：
请求消息：

采用REST推荐的方式，URI+Parameters。
返回消息：
<?xml version=”1.0″ encoding=”UTF-8″?>
<ResultSet xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns=”urn:yahoo:maps”
xsi:schemaLocation=”urn:yahoo:maps http://local.yahooapis.com/MapsService/V1/GeocodeResponse.xsd”>
<Result precision=”address”>
<Latitude>37.416384</Latitude>
<Longitude>-122.024853</Longitude>
<Address>701 FIRST AVE</Address>
<City>SUNNYVALE</City>
<State>CA</State>
<Zip>94089-1019</Zip>
<Country>US</Country>
</Result>
</ResultSet>
SOAP的精简xml返回，其他信息，例如出错码等信息由Http协议头来承载。

YouTube：
请求消息：
可以看到对于资源操作的URI定义也是参数的一部分。
返回消息：
<?xml version=”1.0″ encoding=”utf-8″?>
<ut_response status=”ok”>
<user_profile>
<first_name>YouTube</first_name>
<last_name>User</last_name>
<about_me>YouTube rocks!!</about_me>
<age>30</age>
<video_upload_count>7</video_upload_count>
</user_profile>
</ut_response>
自定义的类SOAP消息。

Amazon：
请求消息：
https://Amazon FPS web service end point/?AWSAccessKeyId=Your AWSAccessKeyId
&Timestamp=[Current timestamp] &Signature=[Signature calculated from hash of Action and Timestamp]
&SignatureVersion=[Signature calculated from hash of Action and Timestamp]
&Version=[Version of the WSDL specified in YYYY-MM-DD format] &Action=[Name of the API]
&parameter1=[Value of the API parameter1] &parameter2=[Value of the API parameter2]
&…[API parameters and their values]
返回消息：
类似于SOAP的自有协议，消息体中包含了消息状态等附加信息。

总结：
看了上面那么多网站的设计，总结一下主要有这么几种设计方式。

请求消息设计：
1． 基本符合REST标准方式：资源URI定义（资源．操作）+参数。这类设计如果滥用get去处理其他类型的操作，那么和2无异。
2． REST风格非REST思想：资源URI定义+参数（包含操作方法名）。其实就是RPC的REST跟风。
3． 类似于SOAP消息，自定义协议，以xml作为承载。（可扩展，例如鉴权，访问控制等），不过那就好比自己定义了一套SOAP和SOAP extends。大型的有实力的网站有的采取此种做法。

响应消息设计：
1.       REST标准方式，将Resource State传输返回给客户端，Http消息作为应用协议而非传输协议
2.       以XML作为消息承载体，Http作为消息传输协议，处理状态自包含。
3.       自定义消息格式，类似于SOAP，提供可扩展部分。

作为遵循REST的理念来看我的选择是响应1和请求1的设计。

REST和ASF的集成
ASF要集成REST就现在来看有两种比较合适的方法。
一．就是采用Axis2的REST实现，这种方式的好处就是开发周期短，容易集成，但是请求和响应的格式无法改变，资源URI设计受限，Axis2的REST其实就是将SOAP消息精简，请求的时候删除了SOAP的头，响应的时候仅仅返回资源信息，如果提供xsd就可以被各种客户端所解析。并非真正的REST。
二．就是采用Restlet开源框架，将Restlet开源框架集成到ASF中，由于Restlet本身就是可内嵌的应用框架，因此集成不成问题，同时Restlet框架只是API结构框架，因此实现和定义完全分开，集成Restlet以后可以自己实现其中的解析引擎也可以采用默认提供的引擎，同时对于内嵌Jetty等多种开源项目的支持，将更多优势融入到了Rest中。看了一下国内也有很多朋友已经关注Restlet开源项目，看了它的架构设计，个人觉得还是比较灵活和紧凑的。

题外话
在写这篇文章以前写了一篇调研报告群发给各个架构师们参考，期待反馈。下午正好和我们的首席架构师聊了一会儿。其实我和他的感觉是一样的，REST是否真的在我们现有的服务框架中需要集成，理解了REST的思想再去看应用场景，那么可以发现如果要完全遵循REST的设计理念来设计接口的话，那么强要去改变现有已经存在的或者还未开发的接口就会落入为了技术而技术，为了潮流而跟风的近地。当然并不否认REST的好，其实我们兄弟公司的一些业务场景有部分的接口十分合适这类设计，面向资源，高效，简洁，易用都能够体现出它的价值。我们将会和我们的兄弟公司合作，也会参考他们的设计理念，在参考当前各个网站的实现情况下，部分的采用这类形式的发布，提供给第三方的ISV，无疑是我现在把REST融入到ASF中最好的理由。
有了需求去做才不会陷入为了技术而技术，毕竟技术是由商业价值驱动的，同样社会上充斥着各种技术的鼓吹，如果稍不留神就会陷入跟风的潮流中。

使用PHP的array_unique()函数允许你传递一个数组，然后移除重复的值，返回一个拥有唯一值的数组。这个函数大多数情况下都能工作得很好。但是，如果你尝试在一个大的数组里使用array_unique（）函数，它会运行地慢一些。

有一个比较好而且更快的函数array_flip()来替代使用array_unique()函数来创建唯一的数组。这个魔法般的函数会交换数组里面每一个元素的键和值，因为键值必须唯一，因此，你会得到跟array_unique()函数一样的结果。

更快的方式实现PHP数组去重

/* 创建一个包含重复值的，一共四个元素的数组 */
$array = array('green','blue','orange','blue');

/* 翻转数组，你将会得到唯一键值的数组
array('green'=>0,'blue'=>1,'orange'=>2); */
$array = array_flip($array);

/* 然后再翻转一次，将键和值重新放置，然后得到数组：array(0=>'green',1=>'blue',2=>'orange'); */
$array = array_flip($array);

因为我们已经移除了一些元素，因此数组看起来不是正常的序列。比如我们可能会得到：array(0=>’A’,2=>’B’,5=>’C’);。在某些情况下，这不是一个问题，但是如果你需要数组的键值保持数字的序列，你可以使用一到两种方法解决键值乱序的问题。

使用array_merge修复数组的keys

添加array_flip之后的函数，将会对数组的键值排序并且让它们恢复到正常的序列，如：0,1,2,3…

$array = array('green','blue','orange','blue');
$array = array_flip($array);
$array = array_flip($array);

/* 使用array_merge()函数修复键值*/
$array = array_merge($array);

注意，这种修复数组键值的方法比使用array_merge()函数稍微快了一点。你也可以在最后一步结合使用array_keys()函数(此函数返回翻转后的值)。然后当你翻转数组的值，键值就会根据顺序创建。

$array = array('green','blue','orange','blue');
$array = array_flip($array);
/* 跟第一个例子一样，但是现在我们先提取数组的键值 */
$array = array_keys($array);

非常简单，比起在大数组使用array_unique函数，有了一个有效的性能提升。