Lorna Mitchell is back with a second installment in her "Building a RESTful PHP Server" series with this new post about handling and routing the incoming requests. (You can find the first part about working with the request here)

This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

In this new post to her blog Lorna Mitchell starts off a new series (based on popular demand) looking at building an RESTful server in PHP. Back to basics - no framework, just PHP.

In the first part of this (probably) 3-part series, we'll begin with the basics. It might seem boring, but the most important thing to get right with REST is parsing all the various elements of the HTTP request and responding accordingly. I've put in code samples from from a small-scale toy project I created to make me think about the steps involved.

Her "basics" include:

• the routing to send everything to the main index file (a "front controller" of sorts) with the .htaccess settings included
• Handling the incoming request with a "Request" class
• Parsing the incoming parameters from the "php://input" stream

New from the XPertDeveloper.com blog there's a tutorial showing how to use the Facebook graph API to get page details via a simple cURL request (cURL PHP support required for the example).

Here is the technique to get the detail of the Facebook page with Graph API and PHP. This is the very easy method to get the Facebook page detail. So Let's see how to get this done. With this method you can get details of any Facebook page [inluding] name, picture, link, website, products, description and if the user can post to it.

The sample code is only a few lines - it uses the Facebook page ID (easy to grab from the URL) and fetches a URL with it as a parameter. The output is returned as a standard PHP object with all of the properties attached (decoded from JSON). This is just one of many methods the Facebook graph API has, so check out their documentation for more methods and details on returned values.

In a new post to his blog Henrik Bjørnskov has a tip on preventing cross-site request forgeries in your Symfony2 forms with the help of a simple Symfony2 configuration setting.

When talking with @jmikola on #Symfony-dev this afternoon we got into the subject of cross site request forgery and symfony2 login forms. And it seems that form-login already supports this but neither of us knew how it worked. So here is another quick tip. This time about securing you login form from cross site attacks.

The key is to define a "csrf_provider" in your security.yml config file and point it to the "form.csrf_provider" provider. He also includes the controller and view code/templating you'll need to get the token included in the form (and validated).

On the PHPClasses blog today the question is posed "can .NET make PHP run faster than the official PHP implementation?" (relating to the use of the Phalanger tool to compile PHP down to .NET assemblies.

Recently Phalanger 3.0 was released introducing numerous improvements in terms of compatibility with the PHP 5.3, interoperability with .NET platform implementations including Mono on Linux, and probably most importantly performance improvements. [...] What motivated this article was that a PHP developer named Rasmus Schultz went on the php.internals mailing list and proposed to switch the official PHP implementation based on Zend for another based on Phalanger.

The post includes some benchmarking results of requests made to a WordPress instance running on various PHP platforms. The Phalanger version came in around 2 seconds faster (average, obviously) than the PHP FastCGI setup. Also included are two suggestions for future PHP versions (v6 anyone?) that could help the language perform even better: Thread-safety for running with less memory waste and the inclusion of a JIT (Just in time compiler - of which a few are mentioned specifically.

In a recent post to his blog Chris Hartjes looks at the idea of better HTTP Request/Response functionality in PHP, more than just the superglobal handling and PECL HTTP extension it has now.

I think the fact that we have $_POST and $_GET lulls some of us into the false sense that we should have $_PUT and $_DELETE objects, since that would map to the commonly-desired set of HTTP verbs that REST likes to use. But what should be inside those things, or should we be moving towards a more Pythonesque solution where a Request object, as part of core or via a only-really-for-the-brave- PECL extension?

He mentions opinions from other PHP community members (Laura Thompson and Elizabeth Smith) and a bit about what he (and I'm sure other developers) are looking for in a more full-featured request/response handling feature.

Christian Weiske has a quick post about a handy PEAR-related project that might be in risk of fading away - a plea for help with pearhub.org.

Troels Knak-Nielsen, father of pearhub, wrote to the pear-dev mailing list: "Unfortunately I have absolutely no time at hand for this project and probably won't for a foreseeable time. I still think it fills a need, so I'd be happy to hand over the keys to anyone who will take it upon them to move the project forward. I'll try to assist as best as I can, but probably won't have much time to spare. But the project is fairly simple anyway, so it should be relatively easy to get the main idea."

If you're interested in hosting or helping out with the project, let Troels know. Pearhub lets any project with a publicly facing repository be installed via a PEAR channel quickly and easily. For more information, see the project's FAQ.

Matthew Wells has a new post that looks at combining Kohana and Gearman to create a system to handle large data processing without slowing down the rest of the application.

A commonly identified bottleneck arises when dealing with large, 'expensive' data. This is commonly seen when an application posts a large volume of well structured data to the API (that some process must be carried out upon), before some form of structured receipt is then returned as a request response. [...] Analysing such a request tends to show high PHP CPU usage with lower database consumption. [...] The structured nature of data exchanged via an API means that we can, relatively simply and reliably, divide the submitted data and process it simultaneously with the help of a great tool called Gearman.

He walks you through the entire process including his initial thoughts on what the system should be and how it should behave when the requests are made. He shares the code he used to implement the system - a simple worker that processes part of the request and returns the results. The command-line calls to run the worker manually for testing are also included.

Joris de Wit has a (very) quick post about a handy tip he found about switching layouts easily with Twig in his Symfony2-based application - a handy ternary sort of switch that can detect when something's an Ajax request.

I just learned about the 'app' global variable in twig. It's very handy for loading a special layout for ajax requests.

The "app" variable allows you get get back at some of the settings of your application and check on special things like the isXMLHttpRequest in his example. For more information about Twig and how you can add it to your application, check out Twig-Project.org. Using it's as simple as adding a phar.

Gonzalo Ayuso has a new post to his blog showing how to make a PHP-based client for a REST API with the help of his handy tool.

Today we're going to create a library to use a simple RESTfull API for a great project called Gzaas. [...] Ok. The API is a simple RESTfull API, so we can use it with a simple curl interface. A few lines of PHP and it will run smoothly. But Gzaas is cool so we're going to create a cool interface too. This days I'm involved into TDD world, so we're going to create the API wrapper using TDD. Let's start.

He starts with his tests, defining checks for fonts, patterns and styles and moves into a sample call that sets configuration options for background color, shadows and visibility. You can find out more about what the service has to offer by reading the documentation and the client Gonzalo has written for it in github.