In this recent post from Jani Hartikainen he looks at the three different categories he sees developers fitting into - "smart-and-get-things-done", smart and "just a" programmer.

The other day I was thinking of programmer types. In a way, I think there are three kinds of programmers when looking at a high level [...] So how do you determine if a programmer goes into one of these categories?

The "just a programmer" is the developer that writes code because it's a better job with little passion. The "smart programmer" are talented developers but they miss the big picture things. The "smart and get things done programmer" can be the most ideal of the three - they're the ones with the vision and passion to really make great applications.

In a new post to his blog Ian Selby looks at working with REST requests in PHP. He includes some of the basics of REST too, for those not completely familiar with the term.

APIs have become a very commonplace part of many popular web sites and services...especially REST APIs. I've already discussed how you can roll your own REST API for your PHP apps, but I've also received countless requests to go over how to actually make RESTful requests. That's exactly what we'll take a look at in this article

His tool of choice is the curl extension, making it simple to create a class wrapper with methods like executePost, executeGet, setAuth and, of course, execute. He outlines the class and gives the code blocks that fit inside each of the major functions. In the end you'll have a class that can make GET, POST, PUT and DELETE requests and be able to correctly parse the response.

On the SmartyCode.com site there's a quick new post about making your Zend Framework site a bit more "green" with a conditional GET feature.

In this article I'll show you a simple approach to enable your Zend Framework application saving lots of precious bandwidth, and thus, making it more end-users friendly, and save on bandwidth costs. This technique involves HTTP conditional GET. This is basically a feature of the HTTP protocol. By sending correct HTTP headers with your application, you enable browsers of your end users to cache pages of your site.

A plugin for the front controller (with a dispatchLoopShutdown method inside) is used to handle the requests and cache their content correctly. They have the cache set at 7200 seconds (2 hours) for a time to live, but its easy to tweak it based on your application. TO use the plugin call the registerPlugin function on the controller object and add it as the very last thing that runs.

The Ask About PHP blog has a tutorial offering CodeIgniter users an alternative to the "no normal GET variables allowed" restriction the framework puts on its URLs - a hack to add those GET values back in as a configuration item.

Codeigniter does allow you to turn on the querystring capability, but that would mean you have to use a pure querystring approach, foregoing the segment-based approached. So, is it possible to mix segments and querystring?

Because of how the segmenting URLs are handled, the order of the parameters is very important as they're passed directly into the controller that way. By bypassing this structure and grabbing the GET variables out of a constant in one of the configuration files in one of two ways - mixing them globally and mixing them locally.

On the SitePoint PHP Blog today Troels Knak-Nielsen takes a deeper look at two of the superglobals a lot of PHP developers take for granted - $_GET and $_POST.

When a PHP script is invoked by a web server, it is as the result of a HTTP request. A HTTP request has a target URI and that URI consists of different parts. One of these parts is the query. As the PHP process starts up, the query gets parsed into an associative array. And for some reason, somebody decided on the unfortunate $_GET, because it's what you use for GET requests - right? Wrong!

He points out that all HTTP requests, regardless if they're GET or POST will have that GET information (not necessarily in $_GET, though). He also mentions another commonly used (and sometimes abused) superglobal - $_FILES. His biggest gripe, though, is that the naming of the variables confuses the developer as to the true content of the HTTP request.

And I won't even comment on the nastiness of $_REQUEST.

In this new post to his blog Stefan Esser looks at cross-site request forgeries and how they can be prevented in PHP 5.3 by two things - the request_order directive in your php.ini and by not using $_REQUEST anymore.

Although PHP 5.3 is still in alpha stage and certain features like the PHAR extension or the whole namespace support are still topics of endless discussions it already contains smaller changes that could improve the security of PHP applications a lot. [...] With request_order it is now possible to control in what order $_REQUEST is created and what variable sources are taken into account. This finally allows removing cookie data from $_REQUEST without removing them from $_COOKIE also.

He explains why the use of $_REQUEST can lead to such problems (and security holes) and notes that its use makes overriding an application's GET or POST values as simple as adding a cookie. There's even a method for creating a Denial of Service attack against a site using $_REQUEST like this. He points to an example similar to this that happened with phpMyAdmin a while back.

His recommendation?

Once PHP 5.3 is out it is recommended for hosters to set request_order to "GP" on all the servers running arbitrary PHP applications to protect applications [and] application developers on the other hand should finally move away from using $_REQUEST for user input.

Recently, Cormac posted this look at a method for lazy loading on variables in an object with the magic __get method.

I used the magic method __get() to load the images into the [Product] object when they were needed. __get() is called whenever something tries to access a variable that is not set or publically accessible, so basically I used that to load the images whenever some other piece of code tried to access Product::images.

He includes a quick bit of code that fires off an internal private method for the class that loads up the images. In his example, if they're already loaded, it never gets called.

For a recent REST web service project, Lorna Mitchell had to put together a server for the remote clients to use. She started with a GET request then moved to handling a POST request then to a PUT request - that's where the difficulty came in:

PHP doesn't have a built-in way to do this, and at first I was a little confused as to how I could reach this information. It turns out that this can be read from the incoming stream to PHP, php://input.

Pulling from that stream gave her the raw data she needed (nicely urlencoded too) that she could parse out and use. She includes a simple example that has a check for the REQUEST_TYPE in the _SERVER superglobal to see how the request should be handled (PUT versus GET).

Padraic Brady has written up a post on how he implemented conditional fetching (GET) as a part of the Zend_Feed component of the Zend Framework.

You see, by default, Zend_Feed is stupid. It will blindly drag in whatever RSS you point it at, parse it, present an accessible API (which is largely an abstract API across PHP DOM), and then merrily sit back while you are driven demented. There is a problem in blindly fetching RSS and parsing it - RSS feeds from a huge number of online sources only change rarely. The rest of the time the feed is unchanged.

The key is in the "Last-Modified" header data of the remote file (and ETag). He shows how to use this knowledge in a simple example - pulling data with a ZFBlog_Aggregate class and dumping the contents into a database table. This code checks the return status for a 304 ("Not modified") and closes out the connection if so. Otherwise it grabs the content and updates the database with the most recent fetch times to compare to the "Last-Modified".

On the PHP in Action blog Dagfinn Reiersol shares a method to send messages across a POST request that's followed by a redirect (versus a simple GET where it can be in the URL).

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.