When processing a GET request, you can display whatever messages you want. The most simplistic way is to echo them directly; or if just slightly more sophisticated, set it in the template that's about to become the web page. When processing a POST request that is to be followed by a redirect, you can't do that. The response (redirect) sent back to the browser does not have any text or HTML content.

He points out two different ways to handle the problem - either manually append the message to the URL you're redirecting to or (a bit better method) store it in a session variable and remove it once its done. Several frameworks call this a "flash message". He gives examples of how to set this in two popular frameworks - Zend Framework and CakePHP.

When processing a GET request, you can display whatever messages you want. The most simplistic way is to echo them directly; or if just slightly more sophisticated, set it in the template that's about to become the web page. When processing a POST request that is to be followed by a redirect, you can't do that. The response (redirect) sent back to the browser does not have any text or HTML content.

He points out two different ways to handle the problem - either manually append the message to the URL you're redirecting to or (a bit better method) store it in a session variable and remove it once its done. Several frameworks call this a "flash message". He gives examples of how to set this in two popular frameworks - Zend Framework and CakePHP.

I've recently been wrapped up in an effort to design and implement a RESTful API using the Atom Protocol for a project at work. We are using the Zend Framework as the underlying framework for the project, so, in order to follow the Atom Protocol, I needed to support the HTTP methods PUT and DELETE

Since the Zend Framework has been playing such a prominent role in the development, he's been digging into the Zend_Rest_Server component code and isn't too happy about its support for PUT and DELETE. As a result, he's proposed methods that might help resolve things such as isGet, isDelete, isOptions and getEntityBody. He' even created a patch to make the needed changes.

The basic idea of a Web 2.0-style "mashup" is that you consume data from several services, often from different providers and combine them in interesting ways. This means you often need to do more than one HTTP request to a service or services. [...] Using the curl_multi* family of cURL functions you can make those requests simultaneously. This way your app is as slow as the slowest request, as opposed to the sum of all requests. And that's something.

He includes example code that loops through a given array of resources and executes the fetch, brining the results back into a result array. To illustrate, he also includes two types of examples of fetching content - one for GET and another for POST.

I have seen more than one person make the following logic mistake: I may get data via GET, I may get data via POST - Ah, I should use $_REQUEST as it will catch both.

Brian points out the error - cookies aren't in $_REQUEST so improper handling of those values could lead to cookie data overwriting GET/POST data from $_REQUEST. Several of the comments on the post also warn against improper handling of the values, noting that doing so could lead to holes open for attacks (like session fixation).

Already, there is talk of how, and if, to leverage PHP 5's object handling now that we don't need to deal with the weirdness of PHP 4's object model. Of course, because it's Drupal, our army of performance czars want to know just what the cost is for object handling, and especially advanced object magic like __get(), __call(), the ArrayAccess interface, and so forth.

He an his tests on a Thinkpad (Intel Core2 Duo 2.2Ghz) running Kubuntu and PHP 5.2.3. They were run two million times benchmarking the different methods for:

• function calls
• __call
• __get
• __set
• iterators (array)
• inheritance
• composition

His results are listed at the end of the post.