Sergey Zhuk has written up a tutorial showing you how to implement promise-based caching with ReactPHP, a continuation of a previous post.

In the previous article, we have already touched caching (when caching DNS records). It is an asynchronous promise-based Cache Component. The idea behind this component is to provide a promise-based CacheInterface and instead of waiting for a result to be retrieved from a cache the client code gets a promise. If there is a value in a cache the fulfilled with this value promise is returned. If there is no value by a specified key the rejected promise returns.

He starts by defining the caching interface and how it would look in use to set/get a cache value. He shows how to update this with a "done" handler to output the value when the get is complete. He continues on showing how to use a fallback handler: either "otherwise" or "then". He also shows how these can be chained together to make more complex operations. The post ends with an example of this caching component in action and links to other library that use the same ideas.

On his Medium blog Peter Lafferty has written up a post showing you a method for HTTP request validation in Silex, the microframework from the creators of Symfony.

This article covers three validation scenarios: routes, query strings [and] POST with a JSON body.

He starts with a simple Silex application that creates a "RESTful" API with endpoints providing emojis back when queried (three endpoints). He then uses this to show how to validate:

• routes for their expected values in the URL
• using a ValidatorService provider to build a set of assertions (GET request)
• using the same service to create assertions for the JSON content of a POST request

All code required is included in the post including the correct handling of the emoji output via a UTF-8 JSON response handler.

On the Zend Developer Zone they've posted the fourth part in their series of tips around using the Z-Ray profiling tool in your PHP applications. In this fourth tip they show you how to "get rid of it" in certain parts of your application.

Well, while Z-Ray is a great friend to have when developing your apps, there are just some parties you don’t want it to show up at. You might be using PHP scripts for accessing static pages. Or, you might not want Z-Ray to be displayed for one specific request. In production, you most definitely don’t want Z-Ray popping up for users using your app!

There are numerous ways to disable Z-Ray both in development and in production to make sure your development workflow is not interrupted and your live apps are not affected. Here are a few of them.

They include a few different ways to disable the tool including the use of a function call in the code (zray_disable), using a header in the HTTP request and, naturally, from the Z-Ray toolbar itself. They also talk about setting it up to be removed for production in one of two modes, either selective (only showing for certain requests) and completely disabled.

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.

On PHPBuilder.com today there's a new tutorial from Jason Gilmore about building a simple RESTful API with Slim, a microframework for PHP.

Although a relatively new entrant in the PHP framework sweepstakes, I've been lately quite intrigued by Slim, a slick RESTful microframework modeled after Ruby's Sinatra, which is coincidentally by far my favorite microframework available for any programming language. In this article I'll show you just how easy it is to get started building a powerful RESTful API using this streamlined framework.

Setup of the framework is as simple as downloading the latest copy from its github repository. It can then be included and used to make the simple routes in his examples. He uses a "games" request type to show how to handle GET, POST and PUT requests through Slim's simple interface.

Web Developer Juice has posted the second part of their series looking at some of the "magic functions" that PHP has to offer - special functions that do automagic things in your scripts and classes. Part one can be found here.

In my previous post ( PHP Magic Functions ), I discussed about __construct, __destruct, __call and __callStatic. Lets explore a few more magic functions...

In this latest part of the series they look at three functions:

• __set/__get
• __invoke

Ole Markus has a new post to his blog looking at a technique for working with memcached and fetching data out of the store using a binary semaphore for better performance.

A typical document takes but a few hundred milliseconds to generate when a single request for the document enters the backend. The problem is that this is a highload website. In its current form, the backend serves hundreds of pages per second. This pretty much guarantees that the backend will concurrently receive cache miss on multiple languages and at the same time also receive cache miss on the pre-translated document.

Given that he wants the translated version to be the one that's always shared, a problem can come up when the cache request is "missed" and the document starts generating from multiple places. His fix for the situation is that only the first miss generates and all others see a lock on it and wait for it to be removed before successfully fetching the result. He provides code in a "LockedMemcached" class to help make it all more useful.

In this new post to the php|architect blog Matt Butcher offers a security tip for all PHP developers out there - never use $_GET again.

You don’t need to use $_GET or $_POST anymore. In fact, you probably shouldn’t use $_GET and $_POST anymore. Since PHP 5.2, there is a new and better way to safely retrieve user-submitted data. [...] Rather than accessing the $_GET and $_POST superglobals directly, you can make use of PHP functions like filter_input() and filter_input_array().

He gives a code example of it in use and talks about the two things these functions do to help keep you safe - validate the data for correct match on criteria and sanitizing the value to ensure the return value is only what's requested. You can find more about these filter functions in the Filters section of the PHP manual.

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.