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.

On NetTuts.com today they've posted the start of a new series looking at the creation of a RESTful API with the help of the Laravel 4 framework (in beta at the time of this post).

RESTful API's are hard! There are a lot of aspects to designing and writing a successful one. For instance, some of the topics that you may find yourself handling include authentication, hypermedia, versioning, rate limits, and content negotiation. Rather than tackling all of these concepts, however, let's instead focus on the basics of REST. We'll make some JSON endpoints behind a basic authentication system, and learn a few Laravel 4 tricks in the process.

Their API example is a "read it later" kind of application where users can store links to URLs they want to read later. They walk you through the installation of the framework, creation/configuration of the database and include the migrations to set it up. From there they help you set up the models, some authentication and routing. Finally, they get to the controllers and the functionality of the application, creating the URL controller to handle the creation, listing and updating of the resources.

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.

Lorna Mitchell is back with another post in her "Building a RESTful PHP Server" series today with this new post showing how to work with output handlers (her focus is on JSON).

So far we've covered parsing requests to determine exactly what the user is asking for, and also looked at routing to a controller to obtain the data or perform the action required. This post gives examples of how to return the data to the client in a good way.

She advocates using output handlers instead of the usual views you'd think of in a typical MVCish sort of application. The difference here is that there's not a lot of extra overhead to produce the results - it's literally an output directly from a class extending the base view (including the correct headers). She also briefly mentions the inclusion of JSONP functionality, allowing you to specify a local callback to execute when the request is returned. A few other "nice to haves" are also mentioned like the number of results returned and pagination support.

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 on PHPBuilder.com today is a tutorial introducing you to web services with the Zend Framework, a guide to creating a simple RESTful service with this popular PHP framework.

Rather than attempt to build and maintain multiple versions of the Web application in order to accommodate the diverse array of challenges and advantages presented by each device type, developers are increasingly embracing a unified approach which allows them to manage a single server-side code base which communicates with multiple client-specific interfaces by way of a RESTful Web service. The Zend Framework's Zend_Rest component offers PHP developers with an incredibly straightforward approach to building RESTful Web services.

He shows how to set up some internal RESTful routing (with the help of Zend_Rest_Route) and create a simple controller that responds to several of the major HTTP request types - POST, GET, PUT, etc. In his simple example, he shows how to update a basic TODO list with a POST and the JSON response that would follow.

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.

Kris Jordan recently posted five tips to help you get a "more correct" REST interface in your application.

As we entered a programmable web of applications with APIs the decision to ignore HTTP gave us problems we're still dealing with today. We have an internet full of applications with different interfaces (GET /user/1/delete vs. POST /user/delete {id=1}). With REST we can say /user/1 is a resource and use the HTTP DELETE verb to delete it.

Here's the five (six?) tips:

• Using PUT and DELETE methods
• Send Custom HTTP/1.1 Headers
• Send Meaningful HTTP Headers
• Don't Use $_SESSION
• Test with cURL or rest-client
• Use a RESTful PHP Framework

The symfony blog points out more new functionality included in the latest version of the framework - a move towards a RESTful architecture.

Yesterday, I have committed the first slew of changes to the routing framework. Thanks to this refactoring, developers have new opportunities to customize the routing and this will allow very cool features in the very near future. But today, let's dive into the goodness of the symfony 1.2 routing framework.

He illustrates the (now built-in) routing functionality that allows you to define customized routes that can do things like pattern matching and can push the output through another external function to handle the results. He also takes a look at the sfRequestRoute component that forces the request to match the route definition