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.

Imagine it's a warm, sunny, summer day. You're just walking along, taking a leisurely noonday stroll, when all of a sudden you come face to face with a RESTful API. What do you do? How do you interface with it? Or, as those of us in the know would say, "how do you consume RESTful services?" That, my friends, is the subject of this article.

They mention using other tools (like components/features of common frameworks) to interface with the services, but end up using the curl extension to make a POST request to a service to add a few events to a "/summerschedule" resource.

As web developers, the applications you write are complex data processing engines. They try and convince your users to enter good, meaningful data and to respond in solid, predictable ways based on what was entered. Robust data validation will allow the rest of you application to work effectively. [...] Data is scrutinized in various ways to make sure that it adheres to basic restrictions and to fundamental properties. It's no good receiving a sandwich when you expect a car.

The questions he answers are:

• Why is Data Validation Important?
• Where Should I be Validating Data?
• When Should My Data Be Validated?
• Who is Responsible for Validation?
• How Do I Validate My Data? (yes, there's a "w" in there!)

In the real world data is ugly, crazy, and untrustworthy. Your only hope to taming the data beast is to diligently, methodically validate your data.

Resting on the foundation of Polymorphism (dynamic Polymorphism, not the ad-hoc one often achieved through plain method overriding), Virtual Proxies are a simple yet solid concept which allows you to defer the construction/loading of expensive object graphs without having to modify client code.

He shows how to create a collection of domain objects that use proxies to populate their data. He includes the code for creating a "Post" interface/object as well as a Comment interface/object. These are put into a "CommentCollection" and, when it's accessed, pull the item in the collection out, only populating the data on demand.

The Kohana Framework started off as a fork of the very popular CodeIgniter Framework. During the KO 2.x versions, it stayed fairly similar to how CodeIgniter functioned, and a developer could easily jump from one to the other and feel very familiar. With the introduction of the Kohana 3.x version, this all changed, as Kohana was completely rewritten from the ground up. Now, unless you're a seasoned PHP developer, you may have difficulty making the jump from other frameworks in Kohana. I have written this tutorial to be your step-by-step guide into the world of Kohana

So far, he's posted three parts of the series:

• Initial setup and configuration
• Bootstrapping the application
• Controller/MVVM/KOstache

Keep an eye on his blog for more posts in this great series!

This is part 2 of "Building RESTful services". In Part 1 we talked about Level 1 and Level 2 of the Richardson Maturity Model. [...] Now imagine if you had to [find the URI] for every single website, each having a different kind of document in a different custom format. The internet would certainly not be what it is today. Yet a majority of the APIs built today make us do this. This is where the hypermedia concept comes in.

He describes the concepts behind hypermedia, giving examples of how this sort of data can be included in your API's responses. To illustrate, he includes some "link" information that then points to other data for things like "moreInfo" and "reviews" in his Book example. He also describes HATEOAS (Hypermedia As The Engine Of Application State) showing how to use this "link" information to make it simpler for the end user/application to navigate around between data sources in the application.

IBM developerWorks has just published the final part in our series on migrating a PHP application from MySQL to DB2. [...] In addition to sharing our own experience, the series highlights the number of resources available to you to carry out your own migration.

The series is broken up into four parts:

• Prepare for your migration
• Migrate your data
• Convert your PHP code
• Deploy your application

In this first of a two part series on web services I'll talk about the SOAP specification and what is involved in creating SOAP messages. I'll also demonstrate how to create a SOAP server and client using the excellent NuSOAP library to illustrate the flow of SOAP. In the second part I'll talk about the importance of WSDL files, how you can easily generate them with NuSOAP as well, and how a client may use a WSDL file to better understand your web service.

He introduces you to the concepts behind SOAP, the normal structure of a SOAP-formatted XML message and what an example might look like for fetching a stock price from a remote service. He then shows how to use NuSOAP to create both a simple server and client to pull information about books - sample code and a screenshot of the output is included.

Does it means that we have to make a choice between flexibility, customization, ease of testing and not having to copy and paste the same code into each application front controller? As you might expect, there is a solution. We can solve all these issues and some more by using the Symfony2 dependency injection container.

The Symfony2 DIC (DependencyInjection) allows you to create a container with the objects and settings that you want and inject that into the main "Framework" class for its use. He registers most of the components he's added over the series like the UrlMatcher, RouterListener, ExceptionListener, EventDispatcher and the Framework class itself. This is all stored in a separate file(s) and can be conditionally included based on your environment. He shows how to register a custom listener, add parameters to the DIC configuration.

If you were to use our framework right now, you would probably have to add support for custom error messages. Right now, we have 404 and 500 error support but the responses are hardcoded in the framework itself. Making them customizable is easy enough though: dispatch a new event and listen to it. Doing it right means that the listener has to call a regular controller. But what if the error controller throws an exception? You will end up in an infinite loop. There should be an easier way, right?

Using the "RouterListener" functionality, he sets up an "ExceptionListener" and points that to an error handling controller with its own "exceptionAction". This action takes the exception information and displays a "Something went wrong!" message along with the details. He also includes an update to the Response handling to allow for returning a string back from the controller instead of a Response object.