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!

Lukas Smith has a new post to his site that asks the question "what's needed to REST in Symfony 2?" In it he talks about some of the current issues surrounding REST support in Symfony (bundles) and a "call to arms" to create something better.

I think we already have quite a nice toolchain for REST in Symfony2 with Bundles like FOSRestBundle, JMSSerializerBundle, NelmioApiDocBundle, FSCHateoasBundle and HautelookTemplatedUriBundle. What is great about these Bundles is that they are all nicely integrated with each other. But there are still some limitations which should be addressed.

Some of the still outstanding issues he points out include issues with content-type and routing, dynamic content in the NelmioApi bundle, Behat context testing, JSONP support and more. He suggests gathering together a product backlog of these items and possibly making a kickstarter to fund its development.

In a new post to his site Justin Carmony shares some of his experiences with doing test-driven development (TDD) for a new project he was working on interfacing with the Omniture API. In it he shares six lessons he learned during the work.

At work we use Omniture for our web analytics, and for a long time I've wanted query our Omniture Data to run some internal reports. I discovered that Omniture has a restful reporting api, and after using it for a little bit I decided it would be nice to write a wrapper library for it. Since I had recently taken the PHP Testing Bootcamp from Chris Hartjes, I decided I wanted write it using Test Driven Development and really get my feet wet. I also decided I wanted to make the library compatible with Composer. After the weekend was over, I had an almost finished library that just requires some more work to be done, but I learned a great deal that I thought I'd share.

He's broken the post up into sections, each with their own summary:

• TDD is 90% changing the way to write code, and 10% writing tests
• Understanding Mock Objects is the real key.
• It takes almost twice as long to write code and tests then just code
• Its extremely easy to get out of the habit of writing tests.
• You'll refactor quicker and more often when writing tests
• Having testable code made me feel much better about sharing the code.

On the Happy Accidents site there's a new post talking about building a RESTful API (part one of the series) using the Orno dependency injection and MVC components.

have recently been writing a collection of PHP components exploring different design patterns for building applications. With the MVC layer close to completion I decided to write a couple of guides on how these components could be wired together to achieve several different application formats. First in this series will highlight the power of OrnoDi when used to resolve your objects, to do this we will be building a simple RESTful api with the minimal amount of configuration and bootstrap code.

He includes instructions to install the components (via Composer) and configure the DI container with the needed settings. He shows examples of the autoloading setup, how to handle the routing and how to create the sample model and controller to respond to the sample REST requests.

Matthew Weier O'Phinney has posted the third part of his series about making RESTful APIs with Zend Framework 2 (parts one and two). In this latest part of the series, he talks more about documenting the API and what commands can be executed.

In this post, I'll be covering documenting your API -- techniques you can use to indicate what HTTP operations are allowed, as well as convey the full documentation on what endpoints are available, what they accept, and what you can expect them to return. [...] hy Document? If you're asking this question, you've either never consumed software, or your software is perfect and self-documenting. I frankly don't believe either one.

He covers a few reasons why you should document your API and where he thinks it should live to be the most useful. He includes a few different ideas and two things he definitely thinks should exist for your API - the use of OPTIONS and end-user documentation. The first is a HTTP header (ZF2 code example included) that tells the API consumer what they can do with an endpoint. The second type is more useful for the human reader, giving them a better overall perspective on what the API can do - still served through the API but in a bit more understandable format.

Lorna Mitchell has officially announced the release of her O'Reilly-published book about creating and working with web services in PHP, PHP Web Services.

I'm delighted to announce that my new book "PHP Web Services" is now available as an early release! [...] The book isn't huge (or expensive, hint!), but it aims to give solid theory in a practical and approachable way. There's the topics you'd expect to see, covering HTTP and verbs and headers and status codes, and also around data formats. It also covers RPC services including SOAP, and also has a chapter (predictably the longest one!) about REST. I've tried to go beyond simply the "how to do" and into the "how to do in a kick-ass manner" realm, so there are chapters about how to design your API and choose what kind to build, how to handle errors, how to make your API really robust - and of course how to debug when things go wrong!

The book not only has the summaries and descriptions of some common web service challenges, but also includes code samples you can use in your own projects.

Matthew Weier O'Phinney has posted the second part of his series looking at creating RESTful APIs with the Zend Framework v2. In the previous post he covered some of the basics of data and structure. In this new article he looks at content types, status codes and two ways to represent them back to your users.

In my last post, I covered some background on REST and the Richardson Maturity Model, and some emerging standards around hypermedia APIs in JSON; in particular, I outlined aspects of Hypermedia Application Language (HAL), and how it can be used to define a generic structure for JSON resources. In this post, I cover an aspect of RESTful APIs that's often overlooked: reporting problems.

He starts with some of the things around error handling and APIs that bother him and why just returning a status code representing an error isn't enough. He suggests two possible solutions to this issue - two messaging formats, API-Problem and vnd.error. He gives brief summaries of each and includes example output to give them some context.

Matthew Weier O'Phinney has posted the first part of a new series he's been working on about creating RESTful APIs with the help of Zend Framework v2. In this part, he looks at things like the "Richardson Maturity Model" and "Hypertext Application Language" as parts of development of the API too.

RESTful APIs have been an interest of mine for a couple of years, but due to circumstances, I've not had much chance to work with them in any meaningful fashion until recently. Rob Allen and I proposed a workshop for PHP Benelux 2013 covering RESTful APIs with ZF2. When it was accepted, it gave me the perfect opportunity to dive in and start putting the various pieces together.

After going over the "Richardson Maturity Model" for the REST structure he spends the rest of the post looking at HAL ("Hypertext Application Language") structure and examples. He mentions the media types it uses, how it handles links between resources and how to embed a resource into the resulting response.

Lorna Mitchell has posted a quick checklist of things you can ask about your API to see if it's RESTful or not (five of them):

I get a lot of emails asking me to get involved with API projects, and that means I see a lot of both implemented and planned "RESTful" APIs. [...] A service of some other description may work better for other scenarios or skill sets, and non-RESTful services can be very, very useful. If you tell me that your service is RESTful, then I expect it to be. If you're not sure, look out for these clues:

• It has a single endpoint
• All requests are POSTs
• Response metadata is in the body, not header
• There are verbs in the URL
• The URL includes method names

She suggests, though, that "being RESTful" isn't a requirement for "being useful" when it comes to APIs.

On the IBM developerWorks site there's a new tutorial posted walking you through the process of creating a REST application with Slim, a popular microframework for PHP.

In this article, I introduce you to Slim, a PHP micro-framework that's designed for rapid development of web applications and APIs. Don't be fooled by the name: Slim comes with a sophisticated URL router and support for page templates, flash messages, encrypted cookies, and middleware. It's also extremely easy to understand and use, and it comes with great documentation and an enthusiastic developer community.

They start off by defining REST in terms of its usual four "verbs" - GET, POST, PUT and DELETE - and the conventions of the types of actions for each. Once you get the framework installed (via Composer) they help you create a sample database with an "articles" table and some sample data your service will work with. They go through each of the "verbs" and include code showing how to respond to the requests for each, including some exceptions for when things go wrong. There's also a bit about adding authentication "middleware" to the process - a hook to validate a user key as a part of the routing process. They finish things off by showing how to support multiple response formats and like XML and JSON based on the requested media type.