Marcelo Gornstein has a recent post to his blog about a method he's come up with to test your PHP-based IVR ("interactive voice response" systems for telephony) applications with the help of PAGI.

Since version 1.9.2, PAGI comes with a mock of a pagi client, suitable to be used in your own unit tests, so you can test your telephony applications, like IVRs. The idea behind the mocked client is to let you test the callflow side of your application, the user interaction and the exact sequence an ivr application should obey. Let's see how to use it.

He shows how to test a basic PAGI application by hooking in the PAGI client into his PHPUnit test for the app and the code coverage of the result. The MockedClientImpl client lets you test the application without having the external dependency of actually running it. He includes some examples of commands and how they'd be mocked out with this client as well as a handy list of the "on*" methods available (like "onDial" or "onSayAlpha").

You can find the complete source for everything in the article on his github account.

On the php|architect site today there's a new article from Luke Stokes asking a question about the future of the web (and web serivces) - is the future in REST or SOAP?

I was recently asked why we chose REST over SOAP for our re-write of the FoxyCart.com API, and the short answer that immediately came to mind was, "Because I don't hate myself". To expand on that answer, let me give you a little bit of the back story.

He talks about their goals for the product and its API, how they wanted to create something useful, built by developers for developers. They leaned towards REST mostly because of the problems and overhead introduced with SOAP (and the complex nature of its requests). He also gives a few reasons why he's "excited about REST": working with known data types, standard interface methods and the fact that it's still such a hot topic of discussion.

These questions [about HATEOS, hypermedia, vendor-specific content types] might seem overwhelming, but for us they are exciting! We believe the future of consistent, powerful API development is being defined right now, and we get to be a part of it.

On the IBM developerWorks site, there's a tutorial from Vikram Vaswani showing you how to connect to Wikipedia's API in your PHP application. It shows how to fetch, search and update entries through their backend. The tutorial's a little bit older (from May 2011) but the content is still relevant.

Wikipedia is the ultimate online encyclopedia, containing millions of entries on different aspects of human knowledge. Web application developers are able to access and search these entries through the Wikipedia API. This article introduces the Wikipedia API and demonstrates it in the context of a PHP application, explaining how to search and retrieve different elements of Wikipedia content with PHP.

He starts with a general introduction to the API including example feed results and URL request formats. From there he moves into the code - a mostly Zend Framework-driven example that uses the REST client. He shows how to make requests for categories, full-text search, grabbing raw page content and adding/editing the content of pages.

Maarten Balliauw has announced the release of a PHP port of a powerful tool for server-side introspection of your applications - Glimpse for PHP.

A few months ago, the .NET world was surprised with a magnificent tool called "Glimpse". Today I'm pleased to release a first draft of a PHP version for Glimpse! Now what is this Glimpse thing… Well: "what Firebug is for the client, Glimpse does for the server... in other words, a client side Glimpse into whats going on in your server."

He includes a of how the introspection works and some sample code using a phar to add it to your PHP application. You can see it in action in this screencast based on the PHP Azure Contest website. He also shows one very cool feature that allows for cross-device tracking of requests. You can find this PHP port of Glimpse on github.

In a recent post to CodeForest Luka Peharda shows you how to create a JSON-RPC frontend for your application based on the Zend Framework.

XML-RPC rules, but the amount of data it generates is its big disadvantage. This is where JSON-RPC steps in. Data it generates is significally smaller, but this isn't suprising as JSON is known as fat free XML.This articles is based on my earlier Android XML-RPC article. Its PHP code and Zend Framework setup will be used so you should go through it if you haven't earlier (at least as far as XMLRPC Android client chapter).

You need to have some of the base code from the previous article in place to follow along, but if you're experienced with Zend Framework, keeping up won't be a problem. He uses this JSON-RPC client that was made for use with a ZF application and creates a basic jsonAction to handle the request. He then uses this Android JSON-RPC library to connect from the Android application and fetch some basic data.

In a follow up to his previous post on using Neo4j with PHP, Josh Adell looks in a bit more detail about how to find paths in the data via a REST interface to the database.

The thing that makes graphing databases useful is the ability to find relationship paths from one node to another. There are many algorithms for finding paths efficiently, depending on the use case.

He includes some code showing the REST request (made via this client) to fetch these street-based relationships. He then creates a little sample script that provides driving directions from one intersection to another with a "findPathsTo" call. He modifies it a bit later on to use the Dijkstra algorithm.

Michael Dowling tipped us off to Guzzle, a RESTful web service client framework that lets you build testable web service clients quickly and easily.

Guzzle helps you speed up the process of creating a RESTful web service client by giving you full control of HTTP requests and access to advanced features like persistent HTTP connections, parallel requests, exponential backoff, over the wire logging, MD5 validation, cookie jars, and a caching forward proxy.

Installing the framework is as easy as grabbing the phar archive and including it in your application. Some sample code examples are included right on the front page - a simple client pulling down an XML file, grabbing Amazon S3 content, working with the HTTP request on a finer scale and making parallel requests.

New on DZone.com today there's an article from Bas De Nooijer talking about a new tool he's created to allow PHP to work directly with Solr (the popular searching platform from the Apache project) as a result of research he'd done from a previous article. The result is < href="https://github.com/basdenooijer/solarium">Solarium, an open sourced PHP client for Solr.

I've worked on a lot of Solr implementations in PHP applications. There are multiple solutions: manual HTTP requests, the solr-php-client library, custom implementations etcetera. However they all have one issue in common: they only handle the communication with Solr, many other important parts like query building are not covered at all. And the parts that are covered are usually over-simplified. [...] At first I developed it as a library for my own projects, but I've decided to turn it into an opensource project. The project is called 'Solarium' and can be found on github: https://github.com/basdenooijer/solarium

You can find complete details about the project over on its wiki including basics concepts of query flow and using the ping/select/update query methods to access your Solr server.

Gonzalo Ayuso had previously shown how to dynamically add watermarks to your images with the help of a mod_rewrite rule. One of the side effects of this is that, with a high load on your server, things can get bogged down quite quickly. His alternative? Add the watermarks to your images with Gearman workers.

In this second solution I will use a gearman worker to generate the watermarks. The benefits of gearman is the possibility of use a pool of workers. We can add/remove workers if our application scales. Those workers can be placed even at different hosts, and we can swap easily from one configuration to another.

He includes some sample scripts to illustrate the process - a Gearman client that'll call the watermarking process and a worker that takes in the image and transforms it with GD to add a new layer for the watermark.

Chris Jones has posted more information to his Oracle blog about the caching and other improvements that come along with the Oracle 11gR2 release that can be used in PHP applications.

Oracle 11.2 brought several improvements to Client Result Caching. CRC is way for the results of queries to be cached in the database client process for reuse. [...] PHP OCI8 as a "client" of the database can use CRC. The cache is per-process, so plan carefully before caching large data sets. Tables that are candidates for caching are look-up tables where the network transfer cost dominates.

Like many of the other server-side tools Oracle has to offer, it's pretty simple to enable this caching. Before you had to add a custom bit to your query to tell it to enable the caching. Now it's as simple as setting it up on the CREATE or ALTER for the table - nothing extra for the developer to do.