In the latest to his site Matthew Setter takes a look at easy routing with RouteMatch in Zend Framework 2 applications. The RouteMatch component gives you better control over your routing and lets you define "match paths" for URL to Controller mappings.

Today using Zend Framework 2 RouteMatch, Router and Request objects, I show you an easy way to dynamically update the current route. It's almost painlessly simple. [...] Well, like most things in web application development, what starts out simply in the beginner often grows more complex over time. So too is my once simple route.

His "simple" route started getting a bit out of control when he added in some pagination to the page (and query for the path match). He wanted to figure out how to re-render data with the same filters but show the next page of data. He shows how to use the RouteMatch component to achieve just this. He creates a custom module with a "listViewToolbar" helper that lets you read the router, request and handle the parameters sent via the URL. The "invoke" method is called to render the toolbar in the page, complete with the new settings.

NetTus.com has followed up their previous article covering some of the basics of the HTTP protocol with this new post, part 2 of the series. They suggest that HTTP, the messaging format of the web, is the one protocol that every web developer should know.

In my previous article, we covered some of HTTP's basics, such as the URL scheme, status codes and request/response headers. With that as our foundation, we will look at the finer aspects of HTTP, like connection handling, authentication and HTTP caching. These topics are fairly extensive, but we'll cover the most important bits.

In this article, they talk about things like the HTTPS secure version of HTTP, server-side connection handling, identification/authorization and working with caching and cache control headers.

On NetTuts.com there's a new tutorial about what they think is the one thing every web developer should understand - the HTTP protocol and how its used in web-based communications.

HTTP stands for Hypertext Transfer Protocol. It's a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol. Let's review this powerful protocol through the lens of a web developer. We'll tackle the topic in two parts. In this first entry, we'll cover the basics and outline the various request and response headers.

They cover some of the basics of the protocol first including its statelessness, the concept of URLs and the HTTP "verbs" (like GET, POST and DELETE). They also briefly cover the HTTP response codes (ex. 200, 304) and the flow of the request and response to and from the web server. They also look at some of the basic HTTP headers and the actual low-level text formats of the requests/responses.

There's a section at the end of the post that links you to a few tools that you can use to view the HTTP messaging happening in your requests, some of which you might already have. They also briefly cover the use of HTTP in a few libraries - ExpressJS, Ruby on Rails and jQuery's Ajax handling.

Jason Fox has a recent post to his site about using "Accept" headers in Zend Framework 2 apps to set the format of the return data from a request.

In this article I detail the process by which you can set up your controller actions in Zend Framework 2 to return either the default HTML, or JSON data depending on the "Accept Header" in the request. It incorporates changes related to a security update added since this very helpful article was written, and expands on some of the intricacies of making your web layer objects better "json providers."

His example uses a "ViewJsonStrategy" and the criteria to look for to determine which version to respond with (HTML or JSON) - the Accept header. It uses the JSON encoder/decoder instead of the built-in PHP one to he could use the included "toJson" method to customize the output of the JSON instead of just returning everything.

On his blog today Hari KT has an Aura Framework-related post about one of its components, the Aura.Http component, and its handling of HTTP requests and responses.

The Aura.Http package provide you the tool to build and send request and response. [...] Probably you may not have bothered too much on building the http response either the framework does it for you, or until you need to send the correct response.

The post shows you how to use the component to send and receive HTTP requests. Code is included showing how to make Response objects and set headers, content, cookies and HTTP response code. He also shows how to output the response and a more complete example of the entire flow. The post finishes up with an example of using Aura.Http to make a request to another site - in this case back to GitHub to get the users on a repository.

The Amazon Web Services group has recently released an updated version of their SDK for PHP and at it's heart is the open source project Guzzle (a HTTP client framework).

The new SDK is built on top of the Guzzle HTTP client framework, which provides increased performance and enables event-driven customization. Each AWS service client extends the Guzzle client and describes operations on the service using a service description file. The SDK now manages persistent connections for both serial and parallel requests. It detects transient network failures, with automatic retries using truncated exponential backoff. Support for event hooks (via the Symfony2 EventDispatcher) allows you to implement custom, event-driven behavior.

In the AWS post about the update, they give you a few code snippets showing this updated version in use. This completely reworked version of the SDK is not compatible with the previous version, so you'll need to consult their migration guide to bring things up to date.

A discussion has started up on Reddit.com about the request for a "$_PUT" superglobal to match the already existing "$_POST" and "$_GET" (as is mentioned in this bug).

Data that is posted to PHP via the PUT method is not parsed at all and is not available to PHP. This is particularly problematic for data sent encoded as 'multipart/form-data'. [...] This is something that would help every RESTful interface that people are trying to do with PHP. There are many people who have these problems and have to implement (usually incomplete and/or buggy) PHP solutions.

In the Reddit post there's a mixed set of opinions - some say that things work well enough as is (content pulled from the raw stream) and others say that adding something like this makes the HTTP support more complete and functional.

Sebastian Göttschkes has a new post to his site showing you how to test secure pages within your Symfony2 applications using a simple "requestWithAuth" method.

If you develop a web application, more often than not you have some kind of user section or admin panel where some kind of login identifies the user and protects your actions against usage from unauthorized people. It can be difficult to do functional tests with this kind of pages as you need to simulate some session or cookie context. In this tutorial, I want to show you how to test your functional pages with symfony2 and phpunit.

He includes a "bad way" to do it, cheating by making a client and feeding it the HTTP auth credentials, and a more correct way involving the "requestWithAuth" method that's called whenever the "request" is called to push those credentials along with every request. Code for this basic function is included.

On DZone.com there's a recent post from Giorgio Sironi listing out some of the HTTP client utilities that can be used in your PHP applications.

In the PHP world, HTTP is very important: not only for receiving requests, which is the job of PHP application, but also for performing them. ROT web services are probably the most popular way to interface with external systems nowadays. We'll make no assumptions on the payload of HTTP requests (which may be binary, text, JSON, XML), so you'll have to deal with that yourself. In some cases, you may choose a more specific solution such as the SoapClient class in the SOAP extension, or the XML-RPC extension.

Among the methods he mentions are things like the cURL extension, the PECL HTTP extension. He also talks about some of the libraries out there that are popular among developers (Buzz and Guzzle) as well as the modules included in the Zend Framework (v1 and v2) to make the requests.

PHPMaster.com has posted the latest tutorial in their series covering RESTful APIS - part four of "REST - Can you do More than Spell it?" In this latest part of the series, they focus on something very key to RESTful services, the HTTP spec (and headers).

We're getting close to the end now, and the only thing remaining is to discuss a little more about the protocol you'll most likely use in any RESTful application that you write. Because HTTP is so often used with REST, that's the protocol I'd like to focus on.

He goes through the structure of a typical (raw) HTTP header and talks about some of the more common headers and what actions/settings they represent. He includes examples of setting headers (with header, naturally) and a curl example showing how to set the request headers. The tutorial is finished off with a brief mention of custom HTTP headers and the the good and bad that comes with them.