In this new post to his site William Durand looks at creating a RESTful API with the help of the Symfony2 framework.

Designing a REST API is not easy. No, really! If you want to design an API the right way, you have to think a lot about everything, and either to be pragmatic or to be an API terrorist. It's not just about GET, POST, PUT, and DELETE. In real life, you have relations between resources, the need to move a resource somewhere else (think about a tree), or you may want to set a specific value to a resource. This article will sum up everything I learnt by building different APIs, and how I used Symfony2, the FOSRestBundle, the NelmioApiDocBundle, and Propel.

It's a long post and covers things very completely with plenty of code samples and descriptions showing you how to use these pieces to make the API. He covers the major HTTP verbs (GET, POST, PUT & DELETE) as well as one of the lesser used ones - PATCH. He also looks at the HATEOAS documentation method and a brief look at using a simple client to do some testing.

In this new post to his blog Chris Hartjes looks at why "monkey patching is for closers" - how it should be avoided in favor of making the code itself more testable rather than "hack" with the patching.

The use of monkey-patching is extremely prevalent in the Ruby community and also to a certain extent in Python usage. I'm not going to go into length about their use of it except to say that it seems quite common and I think most developers are using it as a shortcut to counter what might be poor code architecture decisions.

He includes some example code, excerpted from a blogging system where runkit was originally use to test its functionally. He shows how some simple refactoring (adding input parameters, replacing a static method call, etc) makes it easier to unit test. Comments to the post include further refactoring ideas as well as a response from the original "offender" whose post sparked Chris' response.

Ilia Alshanetsky has a new post to his blog sharing a method for fallback with PDO when your database connection fails.

For our database connections we PDO at work and we've extended the class with PHP to offer some other convenience functionality and wrappers. One of the things I wanted to do recently is allow the constructor of the PDO class to fail-over to our backup database connection pool in the event the primary was not available.

He wanted his code to catch an exception if the object was created with a failed server host and to connect to the backup instead. PDO doesn't cooperate with this method and just destroys the object when there's a failure. His work around is in this patch to the PDO support in PHP to provide a new constant, PDO:: ATTR_KEEP_CLASS_CONN_FAILURE, that tells the script wether or not to destroy the PDO object when there's a problem.

In a new post to his blog Ilia Alshanetsky takes a look at PHP's output buffering feature and some interesting things he found when testing some recent code (hint: it has to do with PHP's "interesting" management of the buffer).

While profiling our application I came across a a rather strange memory usage by the ob_start() function. We do use ob_start() quite a bit to defer output of data, which is a common thing in many applications. What was unusual is that 16 calls to ob_start() up chewing through almost 700kb of memory, given that the data being buffered rarely exceeds 1-2kb, this was quite unusual.

Through a bit more testing he found that, if a buffer provided for content isn't enough, PHP automatically bumps it up by 10kb each time - a waste of resources if you only need a small subset of that. He includes a small patch he made to the PHP core API that allows for defining a custom buffer size and, if it's not enough, bumps up the buffer size by 1kb instead of 10kb.

In the process of some development he's been doing on various shared modules for PHP, Derick Rethans stumbled across an issue with using Valgrind to test his code:

While testing whether I correctly free all memory with Valgrind, I ran into the issue where I couldn't see the stack frames of where the memory leaks occurred in the extensions, and once I even ran into a Valgrind bug. The reason why Valgrind could not show the function names belonging to the stack frames is because PHP had already unloaded the shared extensions from memory.

A work-around he found was compiling the modules, but he wanted something "more correct" and less of a hassle. As a result he added a check for the ZEND_DONT_UNLOAD_MODULES environment flag to the PHP core to handles this case specifically. He includes a snippet of example code showing the Valgrind results with and without the flag.

As a part of one of her projects, Lorna Mitchell had a need to deploy database patches as a part of her overall deployment process. Obviously, doing this manually every time can be a hassle so she came up with a script that does the work for her (based on a patch_history table).

My current project (BiteStats, a simple report of your google analytics data) uses a basic system where there are numbered patches, and a patch_history table with a row for every patch that was run, showing the version number and a timestamp. When I deploy the code to production, I have a script that runs automatically to apply the patches.

The script uses the number-based patch names (such as patch1.sql) and finds the latest ones that haven't been applied based on the highest values for the patch_number column in the database. This number is updated by the patches themselves when they're run to avoid any confusion in the script itself. She has it running as a part of her phing build process as a part of a Zend Framework application.

On the main PHP site there's a new announcement about a critical update in a new version to both the PHP 5.2.x and 5.3.x series of releases to correct a problem that could cause a hang or crash from user input - 5.3.5 and 5.2.17.

The PHP development team would like to announce the immediate availability of PHP 5.3.5 and 5.2.17. This release resolves a critical issue, reported as PHP bug #53632 and CVE-2010-4645, where conversions from string to double might cause the PHP interpreter to hang on systems using x87 FPU registers. The problem is known to only affect x86 32-bit PHP processes, regardless of whether the system hosting PHP is 32-bit or 64-bit. You can test whether your system is affected by running this script from the command line.

All users are strongly encouraged to update their releases. While the problem only happens in certain circumstances, it can still be a huge problem since the data comes directly from the user. For more information about the issue see this post.

Giorgio Sironi has a new post to his blog about a "refactoring" he's done of PHPUnit's mock objects to make their creation with getMock easier.

Not an actual refactoring, but at least the introduction of a layer of indirection, a Parameter object, called PHPUnit_Framework_MockSpecification. I have already written the patch in a branch of my github repository. They are actually two independent patches, since PHPUnit core and the mocking component are in two separate repositories.

If you create a basic object, the creation is simple, but when you start wanting to use one of the other optional parameters down the line, things can get messy. His solution adds methods like disableOriginalConstructor and disableAutoload to make this simpler. You can find the patches on his github account.

UPDATE: This feature has been included in the latest PHPUnit master branch.

For those that have considered contribute back to the WordPress project but weren't sure what the experience might be like, you should check out this helpful post from Aaron Jorbin with his story.