Lorna Mitchell has posted a quick checklist of things you can ask about your API to see if it's RESTful or not (five of them):

I get a lot of emails asking me to get involved with API projects, and that means I see a lot of both implemented and planned "RESTful" APIs. [...] A service of some other description may work better for other scenarios or skill sets, and non-RESTful services can be very, very useful. If you tell me that your service is RESTful, then I expect it to be. If you're not sure, look out for these clues:

• It has a single endpoint
• All requests are POSTs
• Response metadata is in the body, not header
• There are verbs in the URL
• The URL includes method names

She suggests, though, that "being RESTful" isn't a requirement for "being useful" when it comes to APIs.

In this recent post Nikita Popov looks at some of the usefulness of PHP and some responses to this post from Jeff Atwood about the language.

People come to PHP because they have some problem and they need to solve it. This is what PHP really shines at. You can simply take your static HTML website, add a simple <?php include 'counter.php'; ?> in there, and … be done! From there you start writing simple scripts, learn how to process forms, how to talk to the database, etc. After some time you start using object oriented programming and maybe make use of some framework.

He supports Jeff's thoughts on the usefulness of the language, but points out one part of the post that clearly shows an incorrect view of PHP's current state. It points out how "so little has changed in PHP" and Nikita refutes it with some of the most recent updates including advanced OOP support, namespacing and lambda support.

In a new post to his blog Jigal Sanders shares some of his experience in working with Doctrine 2.1 in a Zend Framework-based (1.11.9) application for his database interface needs.

I hadn't been using Doctrine for a while and decided to pick it up two weeks ago, as we wanted to see if we can implement it for our CMS at our office. So I setup a clean installation of the zend framework (1.11.9) and tried tried to implement Doctrine. The main goal was to see if we can reverse engineer existing databases and then start doing some queries.

There were three things he found in the process that caused a few issues:

• A confusing set of terms and features that weren't explained well enough to know their use
• Getting things like autoloaders working with the Zend Framework to make things work well together
• A potential bug with the "name" property on an object and some automatic namespacing Doctrine tries to do

There are already a lot of resources available on the Internet. I have looked at various configurations, like for example the 'bisna' project from Guilhere Blanco. But I keep saying that it's really difficult and has a steep learning curve. Doctrine 1.2 was really simple. Doctrine 2.x is a lot more difficult to get into.

The Ibuildings techPortal has posted the latest episode in their DPC09 session podcast series - a talk from Paul Reinheimer about easy and hard problems.

Consider "Easy" problems in web applications, like login forms. On the surface, terribly simple, slap some escaping functions on a query and you're done! Well, not quite, what about brute force login attempts? Locking accounts? Captachas! This talk will examine a few of those easy problems, how hard they really are, and present specific solutions and methodologies.

You can either listen to this latest episode in-page or download it directly.

In this new post to his blog today, Stuart Herbert suggests something that the PHP community really is in dire need of - a site/resource providing a place developers can point at to help refute some of the PHP rumors floating around and provide examples and test cases for one of the most stubborn PHP markets out there - business.

At work, we make and sell software written in a number of languages; our flagship product is written in PHP.

But one of the unfortunate side-effects of Stefan Esser's much-publicized departure from the PHP Security Team has been an increase in the number of IT staff we're coming across who "believe" both that open-source is inherently insecure, and that PHP in particular has incurable problems. These "beliefs" hurt ISVs trying to sell PHP-based applications into skeptical organizations.

He asks why there is no "Why PHP?" resource out there that clients/businesses in general can be referred to for better information. He also suggests one of the most logical fits for this kind of information and is surprised they don't really have something already - Zend. Check out the comments to see how much of the community is already behind the effort.

From a pointer from the Zend Developer Zone, there's a link to this case study of the creation of a search engine surrounding the Zend_Search component of the Zend Framework.

We have implemented Zend_Search into our content management system "Click and Change" and we would like to share our experiences with the developers' community. For this purpose, we decided to publish the complete source code and it's documentation.

They give a great overview of the application, from some of the interesting things they came across during development to some of the feedback/questions they've already recieved about the project. They have the source code for each of the files in the search engine, including small changes made after the fact. You can also download the entire project in one zipped up file.

Responding to this commentary from the SitePoint PHP Blog the other day, Jonnay has come up with some of his own thoughts on each of the topics mentioned.

Apparently there was some kind of PHP vs. Javascript fight, to see which language sucked the most. The results? Amazingly Banal, if not downright wrong.

Topics in each round of the fight included:

• Syntax
• Standard Libraries
• Meta Programming
• Error Handling
• Garbage Collection

Jonnay comes back with his (differing) perspectives on a few of the items - syntax, scope/namespaces/packaging, meta programming, AOP, and an overall commentary in which he reminds readers that defending either side isn't easy when the voting audience might not fully understand one language or the other.

John Mertic has a quick note on his blog about the latest release candidate for the Windows PHP installer (PHP5.2.0RC3) and some issues they've been having.

Rebuilt the installer for 5.2.0RC3. Edin was having problems building it so I'm going to do it and upload it; hopefully we can resolve the issue.

It's also noted that if you see issues with using the installer, try removing the previous PHP installation before running it again.

Mike Potter has posted an update to his blog about the unofficial Adobe PHP SDK he mentioned earlier with details about new information and corrections that have been added to the guide.

I've updated the (unofficial) Adobe PHP SDK to fix some problems after the initial release. Turns out a few files were missing from the .zip file, and some files were misnamed. I've fixed these problems and also added in a new, more simple sample to show how Flex can retrieve XML data from a PHP backend, without requiring the use of a MySQL database. Finally, I've also removed the .svn files from the .zip file, reducing its size to only 1.5 MB.

You can download this latest version of the guide directly from his blog as well as get involved via the Google Group or requesting access to the SVN repository on Google as well.

The latest version of both major branches of PHP have been released - PHP 4.4.4 and PHP 5.1.5 - fixing some of the major security problems that have been found in recent versions.

PHP development team would like to announce the immediate availability of PHP 5.1.5 and 4.4.4. The two releases address a series of security problems discovered since PHP 5.1.4 and 4.4.3, respectively.

Some of these problems included:

• Added missing safe_mode/open_basedir checks inside the error_log(), file_exists(), imap_open() and imap_reopen() functions.
• Fixed possible open_basedir/safe_mode bypass in cURL extension and on PHP 5.1.5 with realpath cache.
• Fixed a buffer overflow inside sscanf() function.
• Fixed memory_limit restriction on 64 bit system.

All information about the updates for these versions can be found in the Changelogs - PHP 4.4.4 and PHP 5.1.3. It's recommnded that you download these new versions and update your installation.