译者前言：

首先这是一篇国外的英文文章，非常系统、详尽的介绍了如何使用PHP创建REST API，国内这方面的资料非常非常的有限，而且基本没有可操作性。这篇文章写的非常好，只要对PHP稍有了解的程序员，看完本文基本可以自己动手写REST API，花了几个小时翻译过来和大家共享，希望可以帮助大家。转载请注明出处。

本文地址：http://hmw.iteye.com/blog/1190827

原文地址：Create a REST API with PHP

One of the latest (sort of) crazes sweeping the net is APIs, more specifically those that leverage REST. It’s really no surprise either, as consuming REST APIs is so incredibly easy… in any language. It’s also incredibly easy to create them as you essentially use nothing more than an HTTP spec that has existed for ages. One of the few things that I give Rails credit for is its well thought-out REST support, both for providing and consuming these APIs (as its been explained by all the Rails fanboys I work with).

最近互联网上比较热门的一个名词是APIs（接口）,特别是leverage REST。不过考虑到REST APIs在任何语言下都是非常的简单，也就没什么好惊奇的了。同时，它也是非常的容易创建，你基本只需要使用已经存在多年的HTTP规范就可以。我认为Rails语言的为数不多的优点之一就是良好的REST支持，不仅是提供APIs，同时也有很多的客户端支持（我的一些Rails粉丝同事都向我解释了这一点）。

Seriously, if you’ve never used REST, but you’ve ever had to work with (or worse, create) a SOAP API, or simply opened a WSDL and had your head explode, boy do I have good news for you!

认真的讲，假如你从来没有使用过REST，却曾经使用过SOAP API，或者只是简单的打开一个令人头大的WSDL文档。小伙子，我确实要带给你一个好消息！

So, What on Earth is REST? Why Should You Care?

那么，究竟什么是REST？为什么你应该关心？

Before we get into writing some code, I want to make sure everyone’s got a good understanding of what REST is and how its great for APIs. First, technically speaking, REST isn’t specific to just APIs, it’s more of a generic concept. However, obviously, for the sake of this article we’ll be talking about it in the context of an API. So, let’s look at the basic needs of an API and how REST addresses them.

在我们开始写代码之前，我想要确认每个人都可以很好的理解什么是REST以及它是如何特别适合APIs的。首先，从技术上来讲，REST并不是仅仅特定于APIs应用，它更多的是一个通用的概念。然而，很明显，我们这篇文章所讨论的REST就是在接口应用的环境下。因此，让我们看看一个API的基本要求已经REST如何处理他们。

Requests 请求

All APIs need to accept requests. Typically, with a RESTful API, you’ll have a well-defined URL scheme. Let’s say you want to provide an API for users on your site (I know, I always use the “users” concept for my examples). Well, your URL structure would probably be something like, “api/users” and “api/users/[id]” depending on the type of operation being requested against your API. You also need to consider how you want to accept data. These days a lot of people are using JSON or XML, and I personally prefer JSON because it works well with JavaScript, and PHP has easy functionality for encoding and decoding it. If you wanted your API to be really robust, you could accept both by sniffing out the content-type of the request (i.e. application/json or application/xml), but it’s perfectly acceptable to restrict things to one content type. Heck, you could even use simple key/value pairs if you wanted.

所有的APIs都需要接收请求。对于一个RESTful API，你需要一个定义好的URL规则，我们假定你想要提供一个接口给你网站上的用户（我知道，我总是使用”用户”这个概念来举例）。你的URL结构可能类似于这样：”api/users”或者”api/users/[id]“，这取决于请求接口的操作类型。同时，你也需要考虑你想要怎么样接收数据。近来一段时间，很多人正在使用JSON或者XML，从我个人来讲，我更加喜欢JSON，因为它可以很好的和javascript进行交互操作，同时PHP也可以很简单的通过json_encode和json_decode两个函数来对它进行编码和解码。如果你希望自己的接口真正强健，你应该通过识别请求的内容类型（比如application/json或者application/xml）同时允许接收两种格式。但是，限制只接收一种类型的数据也是可以很好的被接受。真见鬼，假如你愿意，你甚至可以使用简单的键/值对。

The other piece of a request is what it’s actually meant to do, such as load, save, etc. Normally, you’d have to come up with some sort of architecture that defines what action the requester (consumer) desires, but REST simplifies that. By using HTTP request methods, or verbs, we don’t need to define anything. We can just use the GET, POST, PUT, and DELETE methods, and that covers every request we’d need. You can equate the verbs to your standard crud-style stuff: GET = load/retrieve, POST = create, PUT = update, DELETE = well, delete. It’s important to note that these verbs don’t directly translate to CRUD, but it is a good way to think about them. So, going back to the above URL examples, let’s take a look at what some possible requests could mean:

GET request to /api/users – List all users

GET request to /api/users/1 – List info for user with ID of 1

POST request to /api/users – Create a new user

PUT request to /api/users/1 – Update user with ID of 1

DELETE request to /api/users/1 – Delete user with ID of 1

一个请求的其他部分是它真正要做的事情，比如加载、保存等。通常来说，你应该提供几种结构来定义请求者（消费者）所希望的操作，但是REST简化了这些。通过使用HTTP请求方法或者动作，我们不需要去额外定义任何东西。我们可以仅仅使用GET,POST,PUT和DELETE方法，这些方法涵盖了我们所需要的每一个请求。你可以把它和标准的增删改查模式对应起来：GET=加载/检索(查，select)，POST=创建(增，Create)，PUT=更新(改，update),DELETE=删除(DELETE)。我们要注意到，这些动词并没有直接翻译成CRUD（增删改查）,但是这个理解它们的一个很好的方法。因此，回到刚才所举的URL的例子，让我们看一下一些可能的请求的含义：

GET request to /api/users – 列举出所有的用户

GET request to /api/users/1 – 列出ID为1的用户信息

POST request to /api/users – 插入一个新的用户

PUT request to /api/users/1 – 更新ID为1的用户信息

DELETE request to /api/users/1 – 删除ID为1的用户

As you hopefully see, REST has already taken care of a lot of the major headaches of creating your own API through some simple, well-understood standards and protocols, but there’s one other piece to a good API…

正如你所希望看到的，REST已经解决了很多令人头疼的创建接口的问题，通过一些简单的，容易理解的标准和协议。但是一个好的接口还要另外一个方面…

Responses 响应

So, REST handles requests very easily, but it also makes generating responses easy. Similar to requests, there are two main components of a RESTful response: the response body, and a status code. The response body is pretty easy to deal with. Like requests, most responses in REST are usually either JSON or XML (perhaps just plain text in the case of POSTs, but we’ll cover that later). And, like requests, the consumer can specify the response type they’d like through another part of the HTTP request spec, “Accept”. If a consumer wishes to receive an XML response, they’d just send an Accept header as a part of their request saying as much (”Accept: application/xml”). Admittedly, this method isn’t as widely adopted (tho it should be), so you have can also use the concept of an extension in the URL. For example, /api/users.xml means the consumer wants XML as a response, similarly /api/users.json means JSON (same for things like /api/users/1.json/xml). Either way you choose (I say do both), you should pick a default response type as a lot of the time people wont’ even tell you what they want. Again, I’d say go with JSON. So, no Accept header or extension (i.e. /api/users) should not fail, it should just fail-over to the default response-type.

所以，REST可以很简单的处理请求，同时它也可以简单的处理响应。和请求类似，一个RESTful的响应主要包括两个主要部分：响应体和状态码。响应体非常容易去处理。就像请求，大部分的REST响应通常是JSON或者XML格式（也许对POST操作来说仅仅是纯文本，我们稍后会讨论），和请求类似，消费者可以通过设置HTTP规范的”Accept”选项来规定自己做希望接收到的响应数据类型。如果一个消费者希望接收到XML响应，他们仅仅需要发送一个包含类似于(”Accept: application/xml”)这样的头信息请求。不可否认，这种方式并没有被广泛的采用（即使应该这样），因此你也可以使用URL后缀的形式，例如：/api/users.xml意味着消费者希望得到XML响应，同样，/api/users.json意味着JSON格式的响应（/api/users/1.json/xml也是一样）。不管你采用哪一种方法，你都需要设定一个默认的响应类型，因为很多时候人们并不会告诉你他们希望什么格式。再次地，我会选择JSON来讨论。所以，没有Accept头信息或者扩展（例如：/api/users）不应该失败，而是采用默认的响应类型。

But what about errors and other important status messages associated with requests? Easy, use HTTP status codes! This is far and above one of my favorite things about creating RESTful APIs. By using HTTP status codes, you don’t need to come up with a error / success scheme for your API, it’s already done for you. For example, if a consumer POSTS to /api/users and you want to report back a successful creation, simply send a 201 status code (201 = Created). If it failed, send a 500 if it failed on your end (500 = Internal Server Error), or perhaps a 400 if they screwed up (400 = Bad request). Maybe they’re trying to POST against an API endpoint that doesn’t accept posts… send a 501 (Not implemented). Perhaps your MySQL server is down, so your API is temporarily borked… send a 503 (Service unavailable). Hopefully, you get the idea. If you’d like to read up a bit on status codes, check them out on wikipedia: List of HTTP Status Codes.

但是和请求有关的错误和其他重要的状态信息怎么办呢？简单，使用HTTP的状态码！这是我创建RESTful接口最喜欢的事情之一。通过使用HTTP状态码，你不需要为你的接口想出error/success规则，它已经为你做好。比如：假如一个消费者提交数据（POST）到/api/users，你需要返回一个成功创建的消息，此时你可以简单的发送一个201状态码（201=Created)。如果失败了，服务器端失败就发送一个500（500=内部服务器错误），如果请求中断就发送一个400（400=错误请求）。也许他们会尝试向一个不接受POST请求的接口提交数据，你就可以发送一个501错误（未执行）。又或者你的MySQL服务器挂了，接口也会临时性的中断，发送一个503错误（服务不可用）。幸运的是，你已经知道了这些，假如你想要了解更多关于状态码的资料，可以在维基百科上查找：List of HTTP Status Codes。

I’m hoping you see all the advantages you get by leveraging the concepts of REST for your APIs. It really is super-cool, and its a shame its not more widely talked about in the PHP community (at least as far as I can tell). I think this is likely due to the lack of good documentation on how to deal with requests that aren’t GET or POST, namely PUT and DELETE. Admittedly, it is a bit goofy dealing with these, but it certainly isn’t hard. I’m also sure some of the popular frameworks out there probably have some sort of REST implementation, but I’m not a huge framework fan (for a lot of reasons that I won’t get into), and it’s also good to know these things even if somebody’s already created the solution for you.

我希望你能看到REST接口的这些优点。它真的超级酷。在PHP社区社区里没有被广泛的讨论真是非常的遗憾（至少我知道的是这样）。我觉得这主要是由于没有很好的文档介绍如何处理除了GET和POST之后的请求，即PUT和DELETE。不可否认，处理这些是有点傻，但是却不难。我相信一些流行的框架也许已经有了某种REST的实现方式，但是我不是一个框架粉丝（原因有很多），并且即使有人已经为你提供了解决方案，你知道这些也是非常有好处的。

If you’re still not convinced that this is a useful API paradigm, take a look at what REST has done for Ruby on Rails. One of its major claims to fame is how easy it is to create APIs (through some sort of RoR voodoo, I’m sure), and rightly so. Granted I know very little about RoR, but the fanboys around the office have preached this point to me many times. But, I digress… let’s write some code!

如果你还是不太自信这是一个非常有用的API范式，看一下REST已经为Ruby on Rails做了什么。其中最令人称道的就是创建接口的便利性（通过某种RoR voodoo，我确信），而且确实如此。虽然我对RoR了解很少，但是办公室的Ruby粉丝们向我说教过很多次。不好意思跑题了，让我们开始写代码。

Getting Started with REST and PHP 开始使用PHP写REST

One last disclaimer: the code we’re about to go over is in no way intended to be used as an example of a robust solution. My main goal here is to show how to deal with the individual components of REST in PHP, and leave creating the final solution up to you.

最后一项免责声明：我们接下来提供的代码并不能被用来作为一个稳健的解决方案。我的主要目的是向大家展示如果使用PHP处理REST的每个单独部分，而把最后的解决方案留给你们自己去创建。

So, let’s dig in! I think the best way to do something practical is to create a class that will provide all the utility functions we need to create a REST API. We’ll also create a small class for storing our data. You could also then take this, extend it, and apply it to your own needs. So, let’s stub some stuff out:

那么，让我们开始深入代码。我认为做一个实际事情做好的方法就是新建一个class，这个class将提供创建REST API所需要的所有功能性方法。现在我们新建一个小的class来存储我们的数据。你可以把它拿去扩展一下然后应用到自己的需求中。我们现在开始写点东西：

class RestUtils
{
	public static function processRequest(){
 
	}
 
	public static function sendResponse($status = 200, $body = '', $content_type = 'text/html'){
 
	}
 
	public static function getStatusCodeMessage($status){
		// these could be stored in a .ini file and loaded
		// via parse_ini_file()... however, this will suffice
		// for an example
        // 这些应该被存储在一个.ini的文件中，然后通过parse_ini_file()函数来解析出来，然而这样也足够了，比如：
		$codes = Array(
		    100 => 'Continue',
		    101 => 'Switching Protocols',
		    200 => 'OK',
		    201 => 'Created',
		    202 => 'Accepted',
		    203 => 'Non-Authoritative Information',
		    204 => 'No Content',
		    205 => 'Reset Content',
		    206 => 'Partial Content',
		    300 => 'Multiple Choices',
		    301 => 'Moved Permanently',
		    302 => 'Found',
		    303 => 'See Other',
		    304 => 'Not Modified',
		    305 => 'Use Proxy',
		    306 => '(Unused)',
		    307 => 'Temporary Redirect',
		    400 => 'Bad Request',
		    401 => 'Unauthorized',
		    402 => 'Payment Required',
		    403 => 'Forbidden',
		    404 => 'Not Found',
		    405 => 'Method Not Allowed',
		    406 => 'Not Acceptable',
		    407 => 'Proxy Authentication Required',
		    408 => 'Request Timeout',
		    409 => 'Conflict',
		    410 => 'Gone',
		    411 => 'Length Required',
		    412 => 'Precondition Failed',
		    413 => 'Request Entity Too Large',
		    414 => 'Request-URI Too Long',
		    415 => 'Unsupported Media Type',
		    416 => 'Requested Range Not Satisfiable',
		    417 => 'Expectation Failed',
		    500 => 'Internal Server Error',
		    501 => 'Not Implemented',
		    502 => 'Bad Gateway',
		    503 => 'Service Unavailable',
		    504 => 'Gateway Timeout',
		    505 => 'HTTP Version Not Supported'
		);
 
		return (isset($codes[$status])) ? $codes[$status] : '';
	}
}
 
class RestRequest
{
	private $request_vars;
	private $data;
	private $http_accept;
	private $method;
 
	public function __construct(){
		$this->request_vars		= array();
		$this->data				= '';
		$this->http_accept		= (strpos($_SERVER['HTTP_ACCEPT'], 'json')) ? 'json' : 'xml';
		$this->method			= 'get';
	}
 
	public function setData($data){
		$this->data = $data;
	}
 
	public function setMethod($method){
		$this->method = $method;
	}
 
	public function setRequestVars($request_vars){
		$this->request_vars = $request_vars;
	}
 
	public function getData(){
		return $this->data;
	}
 
	public function getMethod(){
		return $this->method;
	}
 
	public function getHttpAccept(){
		return $this->http_accept;
	}
 
	public function getRequestVars(){
		return $this->request_vars;
	}
}

OK, so what we’ve got is a simple class for storing some information about our request (RestRequest), and a class with some static functions we can use to deal with requests and responses. As you can see, we really only have two functions to write… which is the beauty of this whole thing! Right, let’s move on…
Processing the Request
好，现在我们有了一个简单的class来存储request的一些信息（RestRequest），和一个提供几个静态方法的class来处理请求和响应。就像你能看到的，我们还有两个方法要去写，这才是整个代码的关键所在，让我们继续…

Processing the request is pretty straight-forward, but this is where we can run into a few catches (namely with PUT and DELETE… mostly PUT). We’ll go over those in a moment, but let’s examine the RestRequest class a bit. If you’ll look at the constructor, you’ll see that we’re already interpreting the HTTP_ACCEPT header, and defaulting to JSON if none is provided. With that out of the way, we need only deal with the incoming data.
处理请求的过程非常直接，但是这才是我们可以有所收获的地方（即PUT/DELETE，大多数是PUT），我们接下来将会讨论这些。但是让我们先来检查一下RestRequest这个class，在构造方法中，你会看到我们已经处理了HTTP_ACCEPT的头信息，并且将JSON作为默认值。这样，我们就只需要处理传入的数据。

There are a few ways we could go about doing this, but let’s just assume that we’ll always get a key/value pair in our request: ‘data’ => actual data. Let’s also assume that the actual data will be JSON. As stated in my previous explanation of REST, you could look at the content-type of the request and deal with either JSON or XML, but let’s keep it simple for now. So, our process request function will end up looking something like this:
我们有几个方法可以选择，但是让我们假设在请求信息的总是可以接收到键/值对：’data’=>真实数据。同时假设真实数据是JSON格式的。正如我前文所述，你可以根据请求的内容类型来处理JSON或者XML，但是让我们现在简单一点。那么，我们处理请求的方法将会类似于这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

public static function processRequest(){
    // get our verb 获取动作
    $request_method = strtolower($_SERVER['REQUEST_METHOD']);
    $return_obj		= new RestRequest();
    // we'll store our data here 在这里存储请求数据
    $data			= array();
 
    switch ($request_method){
        // gets are easy...
        case 'get':
            $data = $_GET;
            break;
        // so are posts
        case 'post':
            $data = $_POST;
            break;
        // here's the tricky bit...
        case 'put':
            // basically, we read a string from PHP's special input location,
            // and then parse it out into an array via parse_str... per the PHP docs:
            // Parses str  as if it were the query string passed via a URL and sets
            // variables in the current scope.
            parse_str(file_get_contents('php://input'), $put_vars);
            $data = $put_vars;
            break;
    }
 
    // store the method
    $return_obj->setMethod($request_method);
 
    // set the raw data, so we can access it if needed (there may be
    // other pieces to your requests)
    $return_obj->setRequestVars($data);
 
    if(isset($data['data'])){
        // translate the JSON to an Object for use however you want
        $return_obj->setData(json_decode($data['data']));
    }
    return $return_obj;
}

Like I said, pretty straight-forward. However, a few things to note… First, you typically don’t accept data for DELETE requests, so we don’t have a case for them in the switch. Second, you’ll notice that we store both the request variables, and the parsed JSON data. This is useful as you may have other stuff as a part of your request (say an API key or something) that isn’t truly the data itself (like a new user’s name, email, etc.).
正如我刚才所说的，非常的简单直接高效。然后，有几点需要注意：首先，我们不接受DELETE请求，因此我们在switch中不提供相应的case条件。其次，你会注意到我们把请求参数和解析后的JSON数据都存储起来了，这在请求中有其他需要处理的数据时会变得非常有用（API key或者其他），这些并不是请求的数据本身（比如一个新用户的名字、电子邮箱等）。

So, how would we use this? Let’s go back to the user example. Assuming you’ve routed your request to the correct controller for users, we could have some code like this:
那么，我们如何使用它呢？让我们回到刚才user的例子。假设你已经通过路由把请求对应到正确的users控制器，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$data = RestUtils::processRequest();
 
switch($data->getMethod){
	case 'get':
		// retrieve a list of users
		break;
	case 'post':
		$user = new User();
		$user->setFirstName($data->getData()->first_name);  // just for example, this should be done cleaner
		// and so on...
		$user->save();
		break;
	// etc, etc, etc...
}

Please don’t do this in a real app, this is just a quick-and-dirty example. You’d want to wrap this up in a nice control structure with everything abstracted properly, but this should help you get an idea of how to use this stuff. But I digress, let’s move on to sending a response.
Sending the Response
请不要在真实的应用中这样做，这是一个非常快速和不干净的示例。你应该使用一个设计良好的控制结构来把它包裹起来，适当的抽象化，但是这样有助于你理解如何使用这些东西。让我们继续代码，发送一个响应信息。

Now that we can interpret the request, let’s move on to sending the response. We already know that all we really need to do is send the correct status code, and maybe some body (if this were a GET request, for example), but there is an important catch to responses that have no body. Say somebody made a request against our sample user API for a user that doesn’t exist (i.e. api/user/123). The appropriate status code to send is a 404 in this case, but simply sending the status code in the headers isn’t enough. If you viewed that page in your web browser, you would get a blank screen. This is because Apache (or whatever your web server runs on) isn’t sending the status code, so there’s no status page. We’ll need to take this into account when we build out our function. Keeping all that in mind, here’s what the code should look like:
既然我们已经可以解析请求，那么接下来我们继续来发送一个响应。我们已经知道我们真正需要去做的是发送一个正确的状态码和一些响应消息体（例如这是一个GET请求），但是对于没有消息体的响应来说有一个重要的catch（译者：不好意思，实在是不知道如何翻译这个词）。假定某个人向我们的user接口发送一个请求某个用户信息的请求，而这个用户却不存在（比如：api/user/123），此时系统发送最合适的状态码是404。但是简单的在头信息中发送状态码是不够的，如果你通过网页浏览器浏览该页面，你会看到一个空白页面。这是因为apache服务器（或者其他服务器）并不会发送此状态码，因此没有状态页面。我们需要在构建方法的时候考虑到这一点。把所有的东西都考虑进去，代码会类似于下面这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

public static function sendResponse($status = 200, $body = '', $content_type = 'text/html'){
    $status_header = 'HTTP/1.1 ' . $status . ' ' . RestUtils::getStatusCodeMessage($status);
    // set the status
    header($status_header);
    // set the content type
    header('Content-type: ' . $content_type);
 
    // pages with body are easy
    if($body != ''){
        // send the body
        echo $body;
        exit;
    }
    // we need to create the body if none is passed
    else
    {
        // create some body messages
        $message = '';
 
        // this is purely optional, but makes the pages a little nicer to read
        // for your users.  Since you won't likely send a lot of different status codes,
        // this also shouldn't be too ponderous to maintain
        switch($status)	{
            case 401:
                $message = 'You must be authorized to view this page.';
                break;
            case 404:
                $message = 'The requested URL ' . $_SERVER['REQUEST_URI'] . ' was not found.';
                break;
            case 500:
                $message = 'The server encountered an error processing your request.';
                break;
            case 501:
                $message = 'The requested method is not implemented.';
                break;
        }
 
        // servers don't always have a signature turned on (this is an apache directive "ServerSignature On")
        $signature = ($_SERVER['SERVER_SIGNATURE'] == '') ? $_SERVER['SERVER_SOFTWARE'] . ' Server at ' . $_SERVER['SERVER_NAME'] . ' Port ' . $_SERVER['SERVER_PORT'] : $_SERVER['SERVER_SIGNATURE'];
 
        // this should be templatized in a real-world solution
        $body = '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
                    <html>
                        <head>
                            <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
                            <title>' . $status . ' ' . RestUtils::getStatusCodeMessage($status) . '</title>
                        </head>
                        <body>
                            <h1>' . RestUtils::getStatusCodeMessage($status) . '</h1>
                            ' . $message . '
 
                            <hr />
                            <address>' . $signature . '</address>
                        </body>
                    </html>';
 
        echo $body;
        exit;
    }
}

That’s It! We technically have everything we need now to process requests and send responses. Let’s talk a bit more about why we need to have a standard body response or a custom one. For GET requests, this is pretty obvious, we need to send XML / JSON content instead of a status page (provided the request was valid). However, there’s also POSTs to deal with. Inside of your apps, when you create a new entity, you probably fetch the new entity’s ID via something like mysql_insert_id(). Well, if a user posts to your API, they’ll probably want that new ID as well. What I’ll usually do in this case is simply send the new ID as the body (with a 201 status code), but you could also wrap that in XML or JSON if you’d like.
就这样，从技术上来说，我们已经具备了处理请求和发送响应的所有东西。下面我们再讨论以下为什么我们需要一个标准的相应提或者一个自定义的。对于GET请求来说，非常明显，我们需要发送XML/JSON内容而不是一个状态页（假设请求是合法的）。然后，我们还有POST请求要去处理。在你的应用内部，当你创建一个新的实体，你也许需要使用通过类似于mysql_insert_id()这样的函数得到这个实体的ID。那么，当一个用户提交到你的接口，他们将很可能想要知道这个新的ID是什么。在这种情况下，我通常的做法是非常简单的把这个新ID作为响应的消息体发送给用户（同时发送一个201的状态码头信息），但是如果你愿意，你也可以使用XML或者JSON来把它包裹起来。

So, let’s extend our sample implementation a bit:
现在，让我们来扩展一下我们的例子，让它更加实际一点：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

switch($data->getMethod){
	// this is a request for all users, not one in particular
	case 'get':
		$user_list = getUserList(); // assume this returns an array
 
		if($data->getHttpAccept == 'json'){
			RestUtils::sendResponse(200, json_encode($user_list), 'application/json');
		}else if ($data->getHttpAccept == 'xml')	{
			// using the XML_SERIALIZER Pear Package
			$options = array
			(
				'indent' => '     ',
				'addDecl' => false,
				'rootName' => $fc->getAction(),
				XML_SERIALIZER_OPTION_RETURN_RESULT => true
			);
			$serializer = new XML_Serializer($options);
 
			RestUtils::sendResponse(200, $serializer->serialize($user_list), 'application/xml');
		}
 
		break;
	// new user create
	case 'post':
		$user = new User();
		$user->setFirstName($data->getData()->first_name);  // just for example, this should be done cleaner
		// and so on...
		$user->save();
 
		// just send the new ID as the body
		RestUtils::sendResponse(201, $user->getId());
		break;
}

Again, this is just an example, but it does show off (I think, at least) how little effort it takes to implement RESTful stuff.
Wrapping Up
再一次说明，这是一个例子，但它确实向我们展示了（至少我认为是）它能轻而易举的实现RESTful接口。

So, that’s about it. I’m pretty confident that I’ve beaten the point that this should be quite easy into the ground, so I’d like to close with how you can take this stuff further and perhaps properly implement it.
所以，这就是它。我非常的自信的说，我已经把这些解释的非常清楚。因此，我就不再赘述你如何具体实现它。

In a real-world MVC application, what you would probably want to do is set up a controller for your API that loads individual API controllers. For example, using the above stuff, we’d possibly create a UserRestController which had four methods: get(), put(), post(), and delete(). The API controller would look at the request and determine which method to invoke on that controller. That method would then use the utils to process the request, do what it needs to do data-wise, then use the utils to send a response.
在一个真实的MVC应用中，也许你想要做的就是为你的每个接口创建一个单独的控制器。例如，利用上面的东西，我们可以创建一个UserRestController控制器，这个控制器有四个方法，分别为：get(), put(), post(), 和 delete()。接口控制器将会查看请求类型然后决定哪个方法会被执行。这个方法会再使用工具来处理请求，处理数据，然后使用工具发送响应。

You could also take it a step further than that, and abstract out your API controller and data models a bit more. Rather than explicitly creating a controller for every data model in your app, you could add some logic into your API controller to first look for an explicitly defined controller, and if none is found, try to look for an existing model. For example, the url “api/user/1″, would first trigger a lookup for a “user” rest controller. If none is found, it could then look for a model called “user” in your app. If one is found, you could write up a bit of automated voodoo to automatically process all the requests against those models.
你也许会比现在更进一步，把你的接口控制器和数据模型抽象出来，而不是明确的为每一个数据模型创建控制器，你可以给你的接口控制器添加一些逻辑，先去查找一个明确定义好的控制器，如果没有，试着去查找一个已经存在的模型。例如：网址”api/user/1″将会首先触发查找一个叫user的最终控制器，如果没有，它会查找应用中叫user的模型，如果找到了，你可以写一个自动化的方法来自动处理所有请求这个模型的请求。

Going even further, you could then make a generic “list-all” method that works similar to the previous paragraph’s example. Say your url was “api/users”. The API controller could first check for a “users” rest controller, and if none was found, recognize that users is pluaralized, depluralize it, and then look for a “user” model. If one’s found, load a list the list of users and send that off.
再进一步，你可以建立一个通用的”list-all”方法，就像上面一段中的例子一样。假定你的url是”api/usrs”，接口控制器首先会查找叫users的控制器，如果没有找到，确认users是复数，把它变成单数，然后查找一个叫user的模型，如果找到了，加载一个用户列表然后把他们发送出去。

Finally, you could add digest authentication to your API quite easily as well. Say you only wanted properly authenticated users to access your API, well, you could throw some code like this into your process request functionality (borrowed from an existing app of mine, so there’s some constants and variables referenced that aren’t defined in this snippet):
最后，你可以给你的接口添加简单的身份验证。假定你仅仅希望适当的验证访问你的接口的用户，那么，你可以在处理请求的方法中添加类似于下面的一些代码（借用我的一个现有应用，因此有一些常量和变量在这个代码片段里面并没有被定义）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

			// figure out if we need to challenge the user
			if(empty($_SERVER['PHP_AUTH_DIGEST']))
			{
				header('HTTP/1.1 401 Unauthorized');
				header('WWW-Authenticate: Digest realm="' . AUTH_REALM . '",qop="auth",nonce="' . uniqid() . '",opaque="' . md5(AUTH_REALM) . '"');
 
				// show the error if they hit cancel
				die(RestControllerLib::error(401, true));
			}
 
			// now, analayze the PHP_AUTH_DIGEST var
			if(!($data = http_digest_parse($_SERVER['PHP_AUTH_DIGEST'])) || $auth_username != $data['username'])
			{
				// show the error due to bad auth
				die(RestUtils::sendResponse(401));
			}
 
			// so far, everything's good, let's now check the response a bit more...
			$A1 = md5($data['username'] . ':' . AUTH_REALM . ':' . $auth_pass);
			$A2 = md5($_SERVER['REQUEST_METHOD'] . ':' . $data['uri']);
			$valid_response = md5($A1 . ':' . $data['nonce'] . ':' . $data['nc'] . ':' . $data['cnonce'] . ':' . $data['qop'] . ':' . $A2);
 
			// last check..
			if($data['response'] != $valid_response)
			{
				die(RestUtils::sendResponse(401));
			}

kill -9 `ps aux|grep commitlog|awk ‘{print $2}’`

______________________________________

建立帐号

#groupadd cvs

#useradd  cvsroot -g cvs

______________________________________

检查是否存在cvs端口服务，防火墙需要打开2401的权限。

#more /etc/services | grep cvspserver

看看是否有:

cvspserver  2401/tcp #CVS client/server operations

cvspserver  2401/udp #CVS client/server operations

______________________________________

#vi /etc/xinetd.d/cvspserver

service cvspserver

{

disable = no

flags           = REUSE

socket_type     = stream

wait            = no

user            = root

server          = /usr/bin/cvs

server_args     = -f –allow-root=/fse/CVS_REP/cvs_docs   –allow-root=/fse/CVS_REP/cvs_classes pserver

log_on_failure  += USERID

}

______________________________________

初始化CVS

#su cvsroot

#cvs -d /fse/CVS_REP/cvs_docs init

#cvs -d /fse/CVS_REP/cvs_classes init

______________________________________

重启服务

#/etc/init.d/xinetd restart

如果没有 xinetd 可以执行

#yum install xinetd

______________________________________

检查CVS服务

#netstat -l | grep cvspserver

此处需打开防火墙的 2401 端口    (如果没有开启防火墙，不用做这一步)

vi  /etc/sysconfig/iptables

在后面加

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 2401 -j ACCEPT

可在windows cmd: telnet 192.168.1.199 2401 检查是否打开

______________________________________

导入程序

-先进入到网站的根目录下 cd /ROOT/www/docs

cvsroot$ cvs -d /fse/CVS_REP/cvs_docs import -m “new www” docs vendor_tag release_tag

______________________________________

分配cvs帐号的脚本 adduse

vi /ROOT/CVS_REP/adduser.sh
给予执行权限
chmod +x

/ROOT/CVS_REP/adduser.sh

以下是文件内容 (”exp,“后面是执行范例，需要在 /ROOT/CVS_REP/文件夹下执行)

#!/usr/bin/perl

# Simple script to take a username and password and

# return a line suitable for pasting into the CVS

# password file

// 添加用户

# exp: ./adduser.sh wangcy 123456 cvsroot >> cvs_other/CVSROOT/passwd

($u,$p,$g)=@ARGV;

@d=(A..Z,a..z);

$s=$d[rand(52)].$d[rand52];

print $u.”:”.crypt($p,$s).”:”.$g.”\n”;

______________________________________

提交cvs的同时发布新的代码到docs目录中

#vi cvs_other/CVSROOT/loginfo 最后一行增加

docs /fse/CVS_REP/cvs_docs/CVSROOT/log.in %s -f /fse/CVS_REP/cvs_docs/CVSROOT/commitlog  -a /fse/docs

log.in文件内容及说明详见
http://www.wangchao123.com/2011/12/05/747

http://www.cnblogs.com/oxo/articles/472518.html

文件下载

/home/cvsroot/test/CVSROOT/loginfo 文件用于控制仓库中版本变更和目录添加之后，log 信息发送到哪里的控制。 loginfo相当于是一个事件驱动器，只要提交了新的版本到cvs中就会触发里面的程序。 loginfo 文件有一个标准的脚本 hook 形式(参阅 Trigger Scripts)，每一行是一个正则表达式和所执行的命令。它支持 ALL 和 DEFAULT 关键字。 调用任何指定的脚本: commit 每个目录一次，在此目录中的所有文件成功提交之后立即执行。 import 每个 import 一次，完成所有写操作之后立即执行。 add 成功 add 到目录之后立即执行。 通过 loginfo 调用的任何脚本会从标准输入获得 log 信息。注意过滤程序 必须 从标准输入读 所有 的 log 信息，否则 cvs 将因管道信号打断而失败。 除了通用格式化字符串以外(参阅 syntax)，loginfo 还支持: {stVv} 文件属性，其中: s    文件名 T    目标的标签名，或者在没有相关标签的时候为空字串(通常是主干) V    旧版本号(提交前) v    新版本号(提交后) 例如，有效的格式化字符串是 `%%’, `%s’, `%{s}’ 和 `%{stVv}’。 我们了解了loginfo的功能以后就知道我要做什么，我们将提交到cvs里面的版本能不能直接发行，这样岂不是很方便。下面这个程序就解决了这样的问题。原来程序只是作为版本修改通知，现在我改进以后同时支持发布了。 #! /usr/bin/perl # -*-Perl-*- # # Usage: log.pl [-u user] [[-m mailto] ] [-s] [-V] -a ‘execution dir’ -f logfile ’dirname file ’ # # -u user - $USER passed from loginfo # -m mailto - for each user to receive cvs log reports #                       (multiple -m‘s permitted) # -s - to prevent “cvs status -v“ messages # -V - without ‘-s’, don’t pass ’-v’ to cvs status # -a dirname - to specify actual execution directory # -f logfile - for the logfile to append to (mandatory, #                       but only one logfile can be specified). use strict; use IO::File; my $cvsroot = $ENV{‘CVSROOT’}; # turn off setgid # $) = $(; my $dostatus = 1; my $verbosestatus = 1; my $users; my $login; my $donefiles; my $logfile; my $activedir; my @files; # parse command line arguments # while (@ARGV) { my $arg = shift @ARGV; if ($arg eq ‘-m’) { $users = “$users “ . shift @ARGV; } elsif ($arg eq ‘-u’) { $login = shift @ARGV; } elsif ($arg eq ‘-f’) { ($logfile) && die “Too many ’-f’ args“; $logfile = shift @ARGV; } elsif ($arg eq ‘-a’) { $activedir = shift @ARGV; } elsif ($arg eq ‘-s’) { $dostatus = 0; } elsif ($arg eq ‘-V’) { $verbosestatus = 0; } else { ($donefiles) && die “Too many arguments!\n“; $donefiles = 1; @files = split(/ /, $arg); } } # the first argument is the module location relative to $CVSROOT # my $modulepath = shift @files; my $mailcmd = “| Mail -s ’CVS update: $modulepath’“; # Initialise some date and time arrays # my @mos = (‘January’,'February’,'March’,'April’,'May’,'June’,'July’, ‘August’,'September’,'October’,'November’,'December’); my @days = (‘Sunday’,'Monday’,'Tuesday’,'Wednesday’,'Thursday’,'Friday’,'Saturday’); my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime; $year += 1900; # get a login name for the guy doing the commit. # if ($login eq ‘‘) { $login = getlogin || (getpwuid($<))[0] || “nobody“; } # open log file for appending # my $logfh = new IO::File “>>“ . $logfile or die “Could not open(“ . $logfile . “): $!\n“; # send mail, if there‘s anyone to send to! # my $mailfh; if ($users) { $mailcmd = “$mailcmd $users“; $mailfh = new IO::File $mailcmd or die “Could not Exec($mailcmd): $!\n“; } # print out the log Header # $logfh->print (“\n“); $logfh->print (“****************************************\n“); $logfh->print (“Date:\t$days[$wday] $mos[$mon] $mday, $year @ $hour:“ . sprintf(“%02d“, $min) . “\n“); $logfh->print (“Author:\t$login\n\n“); if ($mailfh) { $mailfh->print (“\n“); $mailfh->print (“Date:\t$days[$wday] $mos[$mon] $mday, $year @ $hour:“ . sprintf(“%02d“, $min) . “\n“); $mailfh->print (“Author:\t$login\n\n“); } # print the stuff from logmsg that comes in on stdin to the logfile # my $infh = new IO::File “< -“; my $cno = 0; my $cdir; foreach ($infh->getlines) { $logfh->print; #print(“cc-> $_“); if($cno == 1){ my $ff = $_; my @nw = split (/:/, $ff) ; $cdir = @nw[1]; } if ($mailfh) { $mailfh->print (“$_“); } $cno++; } undef $infh; $logfh->print (“\n“); #print(“cdir=$cdir“); my $adir = substr $cdir, 0, length($cdir) - 1; #my $asubdir = substr $cdir, 18 ; my $asubdir = substr ($cdir, index($cdir,“/“,5) + 1) ; chomp $asubdir; my $ain = index($modulepath,“/“); my $mopath_sub = substr ($modulepath, $ain+1); # after log information, do an ‘cvs -Qq status -v’ on each file in the arguments. # if ($dostatus != 0) { while (@files) { my $file = shift @files; if ($file eq “-“) { $logfh->print (“[input file was '-']\n“); if ($mailfh) { $mailfh->print (“[input file was '-']\n“); } exec “mkdir -m 755 $activedir/$mopath_sub“; #die “file transfer for latest version failed: $!“; last; } my $rcsfh = new IO::File; my $pid = $rcsfh->open (“-|“); if ( !defined $pid ) { die “fork failed: $!“; } if ($pid == 0) { my @command = (‘cvs’, ’-nQq’, ’status’); if ($verbosestatus) { push @command, ‘-v’; } push @command, $file; exec @command; die “cvs exec failed: $!“; } my $line; while ($line = $rcsfh->getline) { $logfh->print ($line); if ($mailfh) { $mailfh->print ($line); } } #print(“cp $adir/$file $activedir/$mopath_sub,$asubdir \n“); print (“\n  Active Dir : $activedir/$asubdir  \n“); if(index($asubdir,“src/“)==0){ my $tmp_2=substr $asubdir,4; $asubdir = “WebRoot/WEB-INF/classes/$tmp_2“; if(-d “$activedir/$asubdir“){ print(“Dir exists:$activedir/$asubdir \n“); }else{ exec “mkdir -p $activedir/$asubdir“; } } print(“cp $adir/$file $activedir/$asubdir \n“); if(index($asubdir,“/tmp/cvs-“)==0){ exec “cp $adir/$file $activedir“; }else{ exec “cp $adir/$file $activedir/$asubdir“; } #die “file transfer for latest version failed: $!“; undef $rcsfh; } } $logfh->close() or die “Write to $logfile failed: $!“; if ($mailfh) { $mailfh->close; die “Pipe to $mailcmd failed“ if $?; } ## must exit cleanly ## exit 0;

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />

<title>maryma</title>

<script src=”/js/jquery.js” type=”text/javascript”></script>

<script src=”/js/jquery.jqzoom-core.js” type=”text/javascript”></script>

<script src=”/js/slides.min.jquery.js” type=”text/javascript”></script>

<link rel=”stylesheet” href=”/css/jquery.jqzoom.css” type=”text/css”>

<link media=”screen” type=”text/css” href=”/css/css.css” rel=”stylesheet”>

<script src=”/js/slides.min.jquery.js”></script>

<link rel=”stylesheet” href=”/css/slides.css”>

<script src=”/js/jquery.bxSlider.min.js”></script>

<link rel=”stylesheet” href=”/css/bx_styles.css”>

<script>

//写cookies函数

function SetCookie(name,value)//两个参数，一个是cookie的名子，一个是值

{

var Time = 2; //此 cookie 将被保存分钟

var exp = new Date();    //new Date(“December 31, 9998″);

exp.setTime(exp.getTime() + Time*60*1000);

document.cookie = name + “=”+ escape (value) + “;expires=” + exp.toGMTString();

}

function getCookie(name)//取cookies函数

{

var arr = document.cookie.match(new RegExp(“(^| )”+name+”=([^;]*)(;|$)”));

if(arr != null) return unescape(arr[2]); return null;

}

function delCookie(name)//删除cookie

{

var exp = new Date();

exp.setTime(exp.getTime() – 1);

var cval=getCookie(name);

if(cval!=null) document.cookie= name + “=”+cval+”;expires=”+exp.toGMTString();

}

//SetCookie (“kingM”, “1″)

//alert(getCookie(‘kingM’));

var getking=getCookie(‘kingM’);

var player = new ActiveXObject(“MediaPlayer.MediaPlayer”);

var src=”http://t/img/bk.mp3″;

function play(){

if(player.duration>0){

player.play();

} else {

if(getCookie (“time_bging”)){

player.CurrentPosition += getCookie(“time_bging”);

}

player.Open(src);

}

}

function stop(){

player.Stop();

}

function pause(){

player.Pause();

}

if(getking == “1″){

play();

//SetCookie (“kingM”, “1″);

};

//delCookie(“kingM”);

</script>

<!–<bgsound src=”http://t/img/bk.mp3″ loop=”-1″ id=”soundctl”>–>

<script type=”text/javascript”>

$(function(){

$(“.sound_box”).click(function(){

if(getCookie(‘kingM’) == 1)

{

$(“.sound_box”).css(“background”,”url(/img/sound.jpg) bottom no-repeat”);

SetCookie (“kingM”, “0″);

player.pause();

}

else

{

$(“.sound_box”).css(“background”,”url(/img/sound.jpg) top no-repeat”);

SetCookie (“kingM”, “1″);

play();

//player.paly(); 已经开始播放的时候用这个

}

});

if (getCookie(‘kingM’) != 1) { //格式化按钮

$(“.sound_box”).css(“background”,”url(img/sound.jpg) bottom no-repeat”);

}

//离开页面时保存当前播放进度

window.onbeforeunload = function() {

SetCookie (“time_bging”, player.CurrentPosition);

}

})

</script>

这是一篇受密码保护的文章。您需要提供访问密码：

密码：

转载请注明
作者:海底苍鹰
地址:http://blog.51yip.com/php/1039.html

我用php ，curl主要是抓取数据，当然我们可以用其他的方法来抓取，比如fsockopen,file_get_contents等。但是只能抓那些能直接访问的页面，如果要抓取有页面访问控制的页面，或者是登录以后的页面就比较困难了。

1，抓取无访问控制文件

2，使用代理进行抓取

为什么要使用代理进行抓取呢？以google为例吧，如果去抓google的数据，短时间内抓的很频繁的话，你就抓取不到了。google对你的ip地址做限制这个时候，你可以换代理重新抓。

3，post数据后，抓取数据

单独说一下数据提交数据，因为用 curl的时候，很多时候会有数据交互的，所以比较重要的。

在 upload.php文件中，print_r($_POST);利用curl就能抓取出upload.php输出的内容Array ( [name] => test [sex] => 1 [birth] => 20101010 )

4，抓取一些有页面访问控制的页面

以前写过一篇，页面访问控制的3种方法有兴趣的可以看一下。

如果用上面提到的方法抓的话，会报以下错误

You are not authorized to view this page
You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept.

这个时候，我们就要用CURLOPT_USERPWD来进行验证了

5，模拟登录到sina

我们要抓取数据，可能是登录以后的内容，这个时候我们就要用到curl的模拟登录功能了。

打开/tmp下面的cookie文件看一下

# Netscape HTTP Cookie File
# http://curl.haxx.se/rfc/cookie_spec.html
# This file was generated by libcurl! Edit at your own risk.

mail.sina.com.cn    FALSE    /    FALSE    0    SINAMAIL-WEBFACE-SESSID    65223c4bd8900284ed463d2a3e1ac182
#HttpOnly_.sina.com.cn    TRUE    /    FALSE    0    SUE    es%3D8d96db0820c6c79922ad57d422f575e8%26ev%3Dv0%26es2%3Dcddfb8400dc5ca95902367ddcd7f57dd
.sina.com.cn    TRUE    /    FALSE    0    SUP    cv%3D1%26bt%3D1286900433%26et%3D1286986833%26lt%3D1%26uid%3D1445632344%26user%3D%25E5%25BC%25A0%25E6%2598%25A02001%26ag%3D2%26name%3Dzhangying20015%2540sina.com%26nick%3D%25E5%25BC%25A0%25E6%2598%25A02001%26sex%3D1%26ps%3D0%26email%3Dzhangying20015%2540sina.com%26dob%3D1982-07-18
#HttpOnly_.sina.com.cn    TRUE    /    FALSE    0    SID    BihcallomxMx-QZxzGrOlcSQx%2F0B%2F0cmr.NyQ%2F0B%2FcmGGalmarlmcHrcGlSmrmxmfxal_CBZ%2F_afugCmmGirBYHm0Bc%40fr5ciZiGG5i
#HttpOnly_.sina.com.cn    TRUE    /    FALSE    0    SPRIAL    bfb4102951fd5892a3fd5b42d442cd26
#HttpOnly_.sina.com.cn    TRUE    /    FALSE    0    SINA_USER    %D5%C5%D2001

转自: http://www.cnblogs.com/dotey/archive/2011/05/12/2043939.html

基于Xcode4开发第一个iPhone程序：“Hello World”

介绍9个很有发展潜力的PHP开源项目

　　【IT168 专稿】PHP的开源世界可谓相当精彩，其中大家也接触的不少著名的PHP开源项目，比如Drupal、Sugar CMS、Joomla等等，但在本文中，笔者将选取9个最新知名度不是太高，但可在某些方面很实用，目前还在发展阶段，很有潜力的PHP开源项目。相信各位读者看了之后会惊叹：原来PHP还能干这么多事情。

　　1、PHP FOR Android

　　现在，iphone和Android大行其道，拥有它们已经成为一种潮流。而Android的市场份额也变的越来越大。

　　而现在除了可以用JAVA来编写Android应用外，还多了一种选择，那就是可以使用PHP去编写相关的Android应用了，这都要归功于一个开源项目Php For Android(http://phpforandroid.net/)。它实际上是利用了另外一个开源项目Scripting Layer for Android(SL4A)( http://code.google.com/p/android-scripting/)提供的Android接口API去实现的，任何支持SL4A的脚本语言(比如Javascript,Ruby, Perl,PHP,和Python)都能够通过接口直接跟操作系统打交道，编写应用。

　　如果想了解这个项目，可以阅读如下的这篇文章《Build Your First PHP for Android Application》。

　　2、PL/PHP

　　某些数据库任务涉及很复杂的逻辑计算，而不是简单使用几句SQL语句就可以解决问题。为了降低其复杂性，许多数据库的解决方案中提供了存储过程，它在一个子程序中封装了要完成任务的逻辑，这些子任何的功能其实就象PHP中的函数一样。

　　存储过程可以用相应的SQL去编写的，如微软的存储过程使用T-SQL,Oracle则采用PL-SQL。比如PostgreSQL数据库能执行由C,C++,Java，Ruby,Perl,Python编写的存储过程，而有了PL/php 开源项目(https://public.commandprompt.com/projects/plphp/wiki)，现在你可以使用PHP去编写存储过程了。

　　当安装了PL/PHP项目后，你就可以在PostgreSQL下执行使用PHP编写的存储过程了，可以使用你熟悉的PHP语法，十分简单。

　　3、PHP-QT

　　PHP-QT项目(http://developer.berlios.de/projects/php-qt/)允许你使用PHP语言去编写实现QT的功能，也就是说，可以使用PHP-QT去编写一些功能强大的桌面应用。所谓QT是一个跨平台的C++图形用户界面应用程序框架。它提供给应用程序开发者建立艺术级的图形用户界面所需的所用功能。Qt是完全面向对象的，很容易扩展，并且允许真正地组件编程。

　　但有点遗憾的是，这几年这个项目的发展有点迟缓了，如果确实有兴趣的话，建议也去研究下PHP-GTK这个项目(http://gtk.php.net/)

　　4、Phuby

　　最近,Ruby核心团队成员Aaron Patterson完成了phuby,它可以在Rails应用下运行php应用程序。项目的地址在https://github.com/tenderlove/phuby，尽管项目主持人Aaron发布了几个视频去证明phuby能让php在Rails下运行，但实际上在Rails社区中，估计phuby也只是一个实验品而已。

　　5、另外一个phuby

　　Sean Huber也发布了另外一个同名的项目，居然也叫phuby，但这个跟上面介绍那个是完全没任何关系的。项目地址在https://github.com/huberry/phuby。这个项目为php增加了几个有趣的功能，而只需要在php中设置include_path指向phuby的库位置就可以了。虽然该项目还是处在比较初级的阶段，但其实它已经是综合了php和ruby的一些特点了。

　　6、Objective-PHP and Moka

　　Objective-PHP and Moka are two ambitious projects headed by Stephen Lerodiaconou. TObjective-PHP(https://github.com/stevegeek/moka)和Moka(https://github.com/stevegeek/moka)这两个项目是由Stephen Lerodiaconou.带领研发的很有野心的项目，他们为PHP语言增加了Object-C语言和Cocoa　framework(注：Cocoa是Mac OSX操作系统开发语言)。它们项目中的文档宣称这些新特性能吸引原来的Capucchino开发者。

　　你可以观看这个视频(http://vimeo.com/9838953)去了解这两个框架。

　　7、Php-serial

　　你想通过编写php语言去操纵如视频，音频或计算机的串并口设备?现在是可以变成现实了。使用php-serial这个开源项目(http://code.google.com/p/php-serial/)，可以很容易地去实现。比如只需要调用deviceSet()方法，将串口名传递进去就可以了，接着就可以使用简单的读和写的方法了，比如：

<?
deviceSet(‘COM2‘);
$seria–>deviceOpen();
$serial->sendMessage(‘Sending a message to the port!‘);
$serial->deviceClose();
?>

 　　8、Apns-PHP

　　在苹果的操作系统3.0以上，你可以享受到苹果的推送信息的服务，简称Apple Push Notification Service(APNS)，及时获得各类有用的资讯。

　　现在，你可以使用PHP去实现这个功能了，apns-php项目提供了这个功能，项目的地址在http://code.google.com/p/apns-php/，该项目的文档宣称APNS API在2010年的12月17日已经完成了，可以提供自定义提醒图片和本地化的按钮等新特性。

　　有一篇很好的入门导学文章指导你对apns-php的学习(http://blog.boxedice.com/2009/07/10/how-to-build-an-apple-push-notification-provider-server-tutorial/)

　　9、CFPropertyList

　　cocoa框架使用属性列表来管理序列化数据。这些属性列表可以通过Apple的如plutil等工具进行设置。然而有的开发者希望用他们熟悉的方式去管理这些数据，目前有不少开源项目可以实现这个目的，比如CFPropertyList就是其中之一，项目地址在：

　　https://github.com/rodneyrehm/CFPropertyList，它允许PHP开发者可以创建属性列表，之后发送到iPhone应用。

1.json json编码解码
2.GTMBase64 base64编码解码
3.TouchXML xml解析
4.SFHFKeychainUtils 安全保存用户密码到keychain中
5.MBProgressHUD 很棒的一个加载等待特效框架
6.ASIHTTPRequest http等相关协议封装
7.EGORefreshTableHeaderView 下拉刷新代码
8.AsyncImageView 异步加载图片并缓存代码
9.类似setting的竖立也分栏程序

1.下载排名相关:appannie
2.用户行为分析:flurry
3.majicrank-各国排名查询工具 (推荐)
4.AppViz-App销售统计软件 (推荐)
5.PodViz-用户评论等查看工具
6.appfigures-报表统计分析工具
7.我成立的一个帮助开发者推广app的评测站:苹果I派党

http://www.hackvip.com/mobiwen/html/Mobile_218480.html

上传应用至Android Market需要先到以下账户注册Google Account

https://www.google.com/accounts/NewAccount?continue=http://market.android.com/publish&followup=http://market.android.com/publish&service=androiddeveloper

再使用注册的Google Account注册登录Android Market

https://www.google.com/accounts/ServiceLogin?service=androiddeveloper&passive=true&nui=1&continue=http://market.android.com/publish&followup=http://market.android.com/publish

按提示完成输入注册信息和付费过程，注意：注册过程中需要注册使用Google Checkout完成付费，使用信用卡。

完成Android Developer注册之后按一下教程完成程序上传

http://www.hackvip.com/mobiwen/html/Mobile_218480.html

初学iPhone开发,经过反复多次验证,结合下面2个教程:
http://ameyashetti.wordpress.com/2009/07/31/apple-push-notification-service-tutorial/
http://www.macoscoders.com/2009/05/17/iphone-apple-push-notification-service-apns/

得出从零开始的php版push服务器搭建流程:
==============================================================
0.在Mac OS X机器上安装好XCode, 连接一台正常的iPhone, 保持平和的心态

APP 开发基础设置
1.在iPhone Provisioning Portal中建立好APP ID和Device.
2.在Keychain Access.app中生成证书请求CertificateSigningRequest.certSigningRequest(菜单 > Keychain Access > Certificate Assistant > Request a Certificate From a Certificate Authority…).
3.在iPhone Provisioning Portal > Certificates中请求一个证书(点击Request Certificate,上传CertificateSigningRequest.certSigningRequest).
4.请求完成后,将证书文件(developer_identity.cer)下载,双击导入到Key Chain中.
5.在iPhone Provisioning Portal > Provisioning 中,新建一个Profile, 选择指定的APP ID和 Devices后生成.
6.将刚刚生成的Profile下载为*_profile.mobileprovision, 双击该文件, 将profile加载到iPhone中.

Push Notification service设置
7.在iPhone Provisioning Portal > App IDs,选择需要Push服务的App ID, 进入Configure.
8.确认 Enable for Apple Push Notification service ,配置 Development Push SSL Certificate, 上传第2步生成的证书请求.
9.下载生成的aps_developer_identity.cer, 完成Push服务配置.
10.双击aps_developer_identity.cer,保存到Key Chain.

生成php Push Notification sender需要的证书文件
11.在Keychain Access.app里选定这个新证书(Apple Development Push Services*),导出到桌面,保存为Certificates.p12.
12.运行如下命令:

获得php Push Notification sender所需的设备令牌:
13.新建一个View-based Application项目,在$PROJECT_NAMEAppDelegate.m中:
a.粘贴如下代码:

b.在 – (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 方法中增加

14.项目设置
a.Targets > $APP_NAME > context menu > Properties > Identifier
修改 identifier 为App ID
b.Targets > $APP_NAME > context menu > Build > Code Signing > Code Signing Identifier > Any iPhone OS Device
指定 iPhone Developer 为开发用机
15.编译并运行后会在iPhone上显示设备令牌

16.php Push Notification sender代码如下: