Over on Reddit.com recently a discussion was kicked off asking people what framework they used for REST - their tool of choice for making API creation simple.

I was wondering what people here preferred for setting up REST APIs. Specifically if they had a preferred PHP framework for setting them up. in the past I had used CodeIngiter but am looking at Laravel some recently. I don't anticipate extremely heavy usage but I'd like to easily update the framework when it has new releases without a real pain working around my models and controllers.

Several different options were mentioned in the comments including:

• Flight
• Silex
• Symfony2
• phalcon
• Laravel
• CakePHP

Do you have a favorite you use for your REST APIs? share it here!

PHPMaster.com has posted the second part of their look at the Openbiz Cubi framework (part one here), this time focusing on the code - mostly XML - that you'll need to create your own custom module.

In the first part of this series we talked about the development challenges we face and how Openbiz Cubi can help by providing a solid, ready-to-use web application framework. In this part we'll see how to build our own module and dive a bit deeper into the core architecture of the framework.

They include the SQL you'll need to run to create a new table for the "Customer" module they're going to help you build. With that in place, they walk you through the command to execute to make the module skeleton, the locations of the XML files to work with and the contents of each. Included in the module are things like a data object, a module description file and the form object. He finishes up the post with a look at the overall flow of the Cubi execution so you know where each piece falls.

On the Symfony blog today Fabien Potencier talks about some small things that matter - some of the smaller updates that have been made to the Symfony 2 framework recently that have helped to make it better and more flexible.

Every new Symfony release tries to brings some small but useful improvements. Let's dive into some of them for Symfony 2.3 (in no particular order).

Things in his list include:

• A text-based output of the exception handling stack trace
• A default configuration for the Serializer component
• The ability to run the framework in a production environment in development
• An update to make debugging configuration parameters easier
• Conversion process of short controller names
• Overload generated code in the bundle bootstrapping code

Check out the post for the rest of the changes on his list and check out the RC1 of Symfony 2.3.0 to see some of them in action.

On PHPMaster.com today they've posted the first part of a series spotlighting Openbiz Cubi, a PHP "framework" with a business focus.

Openbiz Cubi is a robust PHP application framework giving developers the ability to create business applications with minimal effort. In this two-part series I'll explain the concepts and steps necessary to create your own business web applications with Cubi. We'll look first at the challenges web developers face and how Openbiz Cubi can help, and then how to install Cubi. In part 2 we'll see how to create our own modules.

They start off by describing the tool and some of the features that come with it (including user management and the XML data object structure). Complete installation instructions are included and a screenshot is included of the end result. They include a "quick tour" of Cubi's features and some of the modules that come with it like the System, Menu and User modules. In part two of the series, they'll show you how to create a custom module.

On PHPMaster.com today there's a new post from Daniel Gafitescu that compares CodeIgniter (an "old standby" in the PHP framework world) and Laravel, a relative newcomer. The article is broken up into a few different categories, with some sample code included to illustrate.

n the beginning of my career I stumble upon CodeIgniter and I love it for its simplicity, small footprint, and good documentation. [...] But last year, because of the Twitter buzz from some in the PHP community, blog posts, and the suggestions of some friends, I give Laravel 3 a try - and since that time I've never looked back. So, in this article I'd like to present a comparison of the two frameworks from my point of view.

He compares the two frameworks based on things like the requirements to get them installed, how they handle creating REST APIs, the general organization of their code (and your code using them) as well as command line support. There's a "miscellaneous" section that talks about some of the smaller differences and a (very) brief mention of the communities for each.

On his site today Lukasz Kujawa has a post that compares some performance benchmarks of several popular PHP frameworks including Slim, CodeIgniter, Laravel, Symfony2 and Zend Framework 2.

There are many assumptions around performance of different PHP frameworks. I frequently hear strong opinions about superiority X over Y in this context. There are companies writing new PHP frameworks from scratch because available solutions are too slow for them. What does it really mean? Does the framework performance matters? Before answering this questions lets check how slow is your framework!

He took the "quick start" projects provided for each of the examples and ran some tests with the Apache Benchmark (ab) tool against EC2 instances, all configured the same way. The results weren't overly surprising with Slim beating the others hands down (it's a micro-framework after all) and Kohana and CodeIgniter coming in second and third. The frameworks with more overhead like Zend Framework and Symfony ranked some of the slowest.

On Reddit's PHP section there's a discussion happening about dependency injection versus service locators in two popular PHP frameworks - Zend Framework 2 and Symfony 2 (and how they're not really DI at all).

Both ZF2 and Symfony 2 offer the same behavior: if I'm in a controller, and I want to use a service, I have to get it from the container with $this->get('my_service'). As such, the controller is not using DI, this is the service locator pattern. Controllers become more difficult to tests because of that, and they depend on the container now. I wonder why both frameworks didn't go further: why not treat controllers like services and use dependency injection on them. In other words: if a controller needs a service "A", then it should get it in the constructor, or through setter/property injection.

The comments talk some about the "controller from the DI container" idea, some other ways around the problem and some clarification as to what the frameworks are actually doing related to the container injection.

Fabien Potencier (of the Symfony framework) has a new post to his site talking about a philosophy that the Symfony framework community should work towards, providing stability over features.

Long story short: in the coming months, the Symfony core contributors should focus their efforts toward stabilizing the existing features instead of working on new ones. At this point, backward compatibility and stability are more important than everything else.

He highlights some of the points that come along with this effort including less refactoring for the sake of refactoring, fixing more bugs/edge cases and writing more tests/documentation. He gets into some of the specifics of this kind of thinking and points out the things that can and can't be changed during this time. He talks more about stability and suggests that not only can it help enhance performance but it could also help motivate more projects/corporate users to start using the framework.

In this recent post to his site, Phil Bennett shares some thoughts about the PHP-FIG, the standards they're proposing and how the shares interfaces might help reduce dependencies in framework-based applications.

[Frameworks] come in several different flavours that all have huge advantages, but also a few disadvantages. Over engineered (because their popularity demands that they be), updated too often, not updated enough. If you decide for example to update your application from using Zend Framework 1 to using Zend Framework 2, this will more than likely require, at least in part, a re-write of your code. This makes scalability difficult.

He talks some about the PSRs that the PHP-FIG group has proposed including the PSR-3 logging interface structure. He points out that, by having this same structure, it makes injecting dependencies easy while still leaving the actual functionality open to interpretation. He also suggests that maybe a framework isn't the right choice for all applications and that possibly using a collection of libraries, tied together by the PSR standards, could be a better answer.

PHPMaster.com has posted a list of six things they think you should think about as you're selecting the framework for your next application.

You've decided that it makes sense to use a framework when writing your next new application, and chances are that if you're already familiar with a specific framework, then you'll probably be leaning towards using that one when you start. But are you sure it's really the most appropriate for the task at hand? In the name of due-diligence, here are some of questions that you should ask yourself before settling on a particular framework to make sure you're not programming "against the grain" and also to make sure it will be able to meet your needs now and in the long-term.

He doesn't get into any specifics of any PHP frameworks out there, but suggests general questions to ask even before getting too deep into the technology:

• What do I need from the framework?
• Do I expect the framework to help manage consistency?
• Is good documentation available?
• Is the framework actively developed, and does it have an active user base?
• Does the framework work in what I run in production?
• What business factors are influencing my decision?

Not every application needs to be written using a framework. But if you've decided that yours does, then it's beneficial to compare your needs against the features and benefits of the various framework offerings.