In an effort to share the REST-related information he's been helping people out with over time, Joshua Thijssen has created a new resource that's less about the basics of REST and more about how to handle specific situations - restcookbook.com.

This is why I decided to setup a simple website, that pretty much tries to answer any question about REST. It's not completed yet.. Actually, it hasn't got many posts to begin with :), but a start has been made and we will fill it with questions and answers about REST and HTTP issues.

As of the time of this post, it only has a few articles, but they're a good start like:

• when to use PATCH
• when to send 400 or 500 codes
• handling an unsatisfied accept-language header

If you're new to PHP (or just want to move up beyond the "beginner" level in your code) you should check out the PHPKnowHow.com site. It offers a complete (and growing) guide to some of the basics of using PHP "in plain English".

PHPKnowHow is a web site about PHP. Our objective is to teach you PHP using simple explanations and digestible examples. If you are new to PHP, begin with Role of PHP in Web Applications. [...] his site is for sharpening your PHP skills. Whether you are an absolute beginner or know bit of PHP already, you would find material here useful.

The main categories right now include content about the basics of the language, working with the PHP configuration (php.ini), using the GET and POST superglobals and a section about MySQL integration.

For those out there using the CakePHP framework to create your applications, you might be interested in these quick tips from Juan Basso on the Zumba Engineering Blog for both the architecture and actual code to optimize the performance of the app.

Our site and system has a lot of throughput and it make us use more instances and try to reduce the load in every part. It makes the company happy (save money) and also make the customer happy (faster load). On this article I will go over few things in terms of architecture and some code changes/strategies that could make your application faster as well.

Some of the recommendations include:

• Installing the APC/opcode caching to help save execution time
• Avoiding as many network requests as possible
• Use local file/data caching
• Using the "requestAction" inside controllers with its built-in caching

PHPMaster.com has posted the latest in their "Practical Code Refactoring" series , this time with a focus on efficiency and how you can refactor your code to help it perform better both in processing power and in resource use.

In part three of this series we dealt with refactoring code for extensibility and discussed logical extensibility, modular design, decoupling, and encapsulation. In this final part of the series, we discuss what the main concerns of efficiency are for your web application and how to refactor for better efficiency.

They talk about some of the things you can do about network bandwidth usage, memory inefficiencies and processing issues (over you doing more work than you need to?). These aren't code examples - every application is different when it comes to this stuff, but it gives you some good questions to ask to fill in the blanks.

Juan Treminio has a new post to his site introducing the ideas behind Pimple and service containers, two very similar approaches to dependency management in your applications.

Recently I've picked up the Silex framework for a project I'm building. It uses a service container for managing dependencies in your application [Pimple], which is great for defining (not instantiating) objects and their default behaviors in a single location, rather than sprinkled throughout your code in a multitude of places. [...] Using Pimple you can define several hundreds of objects, and then easily instantiate them using the container object.

He goes through some example code showing how to use Pimple to create and manage the dependencies by creating several instances of DateTime objects. He shows how this can then be "upgraded" to a service container by defining something like a PDO object (database connection) inside it. He also mentions some of the benefits that come with its use - easy resource swapping, simpler mocking for testing and allows the use of the Inversion of Control pattern.

Gonzalo Ayuso has a new post that responds to the idea that "singletons are a problem when testing" your applications with something like PHPUnit.

Maybe this pattern is not as useful as it is in J2EE world. With PHP everything dies within each request, so we cannot persist our instances between requests (without any persistent mechanism such as databases, memcached or external servers). But at least in PHP we can share the same instance, with this pattern, in our script.

He illustrates a bad side effect of this sharing of resources with a simple unit test that increments a counter in a class. He notes that, because the script shares the object, you can't reliably know the state of it as you don't know what's happened before your use. He recommends two things to help the situation - either not use them at all or destroy the instance each time after using it (counterproductive to using a Singleton, obviously).

On the MaltBlue.com site today there's a new tutorial posted giving you some recommended practices on building an extendible application with the Zend Framework.

Whether you have a big or small budget are time rich or poor, there's always the pressure to build applications with the future in mind. [...] So amongst the multitude of other advice you'll receive throughout your life, building applications that are readily extensible and extendable - in a simple, clean and cost-efficient manner - is essential to keeping input as low as possible, whilst maximising output, and accompanying client satisfaction (or boss satisfaction if you're full-time employed).

He focuses on one aspect of Zend Framework that he's found that helps out the most in keeping his development flexible, resource plugins. These plugins (through use of the Strategy design pattern) can add immediate functionality to your application and be dropped in as needed. He shows how with a simple plugin that allows for simpler file handling for user uploads. The code for the various parts - interface, factory, plugin and resource - are all included.

Security has become more of a hot topic in the PHP community recently and PHPMaster.com has pulled together a list of resources you can read up on to get some great ideas for securing your application.

The unfortunate truth of the matter is there's no excuse for [the LinkedIn, Yahoo!, eHarmony and Last.fm] leaks; they would not have been possible if simple, well-known security precautions were taken. Are you protecting yourself and your applications by guarding against SQL-injection attacks? Are you filtering and validating user input? Are you properly hashing user passwords? I hope so! If not, read some of the security-focused articles PHPMaster has published throughout the past year and apply these best practices to your code today!

Articles in their list include:

• Why You Should Use Bcrypt to Hash Stored Passwords
• Input Validation Using Filter Functions
• Multi-Factor Authentication with PHP and Twilio
• Monitoring File Integrity

Check out the rest of the post for links to other great articles.

As is mentioned in this new post to the CodeIgniter project's main site, their wiki has made a move. You can now find it on github.

In addition to having the convenience of existing as a git repo itself, moving this content to GitHub will help distinguish EllisLab and Reactor created content from community managed resources. It will also reduce the attraction of spammers to the CodeIgniter.com web site, as the wiki was a common location used by spammers and vandals to get content on our site that was less likely to be found and moderated than the frequently visited forums.

You can make changes if you see something incorrect by cloning the repo and making changes to the wiki repo and putting in a pull request.

In this new post to his blog Paul Jones makes a suggestion when you're working with files or external connections in your PHP applications - pass the resource, not the file/path name for more flexibility.

In testing the Aura.Http package, I have realized that it's much more flexible, testing wise, to pass around file resources (a.k.a. handles, pointers, or streams) than it is to pass around file names. When you do that, you can use a php://memory stream instead of attempting to touch the file system.

He shows how using this method can make it easier to test with a simple bit of refactoring by passing in the "php://memory" stream rather than the actual file reference. The comment (from Chris Hartjes) also suggests an alternative tool for working with tests that need the file system, vfsStream.