For those fans of virtualization (and running VMs for development) you're not stranger to VirtualBox. Over on the Google Code site, there's a project that wants to make it easier to work with your VirtualBox instances via a PHP-driven interface.

An open source, AJAX implementation of the VirtualBox user interface written in PHP. As a modern web interface, it allows you to access and control remote VirtualBox instances. Much of its verbage and some of its code is based on the (inactive) vboxweb project. phpVirtualBox was designed to allow users to administer VirtualBox in a headless environment - mirroring the VirtualBox GUI through its web interface.

The tool isn't designed to be a management tool for a "hosting" type of environment, but rather to help you admin all of your VMs at once (no "ownership"). It uses the SOAP service (vboxwebsrv) that comes with VirtualBox servers to create a clean interface.

On the php|architect site today there's a new article from Luke Stokes asking a question about the future of the web (and web serivces) - is the future in REST or SOAP?

I was recently asked why we chose REST over SOAP for our re-write of the FoxyCart.com API, and the short answer that immediately came to mind was, "Because I don't hate myself". To expand on that answer, let me give you a little bit of the back story.

He talks about their goals for the product and its API, how they wanted to create something useful, built by developers for developers. They leaned towards REST mostly because of the problems and overhead introduced with SOAP (and the complex nature of its requests). He also gives a few reasons why he's "excited about REST": working with known data types, standard interface methods and the fact that it's still such a hot topic of discussion.

These questions [about HATEOS, hypermedia, vendor-specific content types] might seem overwhelming, but for us they are exciting! We believe the future of consistent, powerful API development is being defined right now, and we get to be a part of it.

On PHPMaster.com today they've posted the second part of their series looking at creating a SOAP web service with NuSOAP. (Part one is here)

In this article we'll talk about what WSDL files are and how to use them. I'll show you how to quickly build your WSDL files with NuSOAP and incorporate a WSDL file into the SOAP server and client examples from the first part.

He introduces WSDL files, the specially formatted XML definitions that tell SOAP clients what's available on the service and includes some markup as examples. Creating one from scratch ca be a hassle, so it's handy that NuSOAP generates one for you from your server class. He includes sample code to create this generated file and how to create a SOAP client pointed to the PHP script to get the result.

On PHPMaster.com today there's a new tutorial posted, the first part in a series, showing how to create SOAP web services with the help of the NuSOAP library.

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.

New from the King Foo blog there's a tutorial showing how to use complex types in a SOAP request with Zend_Soap, a component of the Zend Framework.

To be able to use complex types with Soap requests, they need to be fully defined in the WSDL file. Zend_Soap can automate this process, if you know how to define those complex types. Let us start without it Zend_Soap's magic and compare it with a fully discovered complex request type afterwards.

In their example, they have a collection of books (objects) that they want to send over to the web service. The code for both the server and client side are included with the WSDL automagically created by the Zend_Soap_Server component. By setting docblock comments on the properties of the Book objects, the SOAP components automatically know what types they are. Their example defines these, and sets up the web service on the other side with a classmap to define where the "tags" information for each book lies.

On the Ldeveloper Tech Blog today there's a helpful new post about an error PHP's SOAP extension could throw about not being able to connect to the host despite all settings being correct.

I receive this nasty error yesterday and it took me some time to figure out the problem: "Fatal error: Uncaught SoapFault exception: [HTTP] Could not connect to host in...". This ["new SoapClient"] line passes without any problems and this [var_dump on __getFunctions] shows the function prototypes correctly.

His script connects to the service as its supposed to but the "could not connect" is still thrown. He found a few references to OpenSSL issues that could cause it, but his code was correct so he turned to the other side - the service itself. As it turns out, it wasn't configured correctly.

It was configured to send invalid url and the function calls were using that invalid url. So there are two solutions [...] the first is to configure the server correctly. The other is to give __doReguest the correct location.

In a recent post Eran Galperin takes a look at the PayPal API and breaks it down into smaller, easy to digest chunks to show you how to you can implement it in your application. Be warned, though - he mentions that it's the "among the worst API he's ever had to deal with" for several reasons.

PayPal is the most popular platform for receiving online payments. The relative ease of opening a PayPal account and receiving payments compared to opening a merchant account for a traditional payment gateway is the number one reason, and another is the comprehensive API they provide for their payment services. [...] There doesn't seem to be any better alternatives currently, so hopefully this guide will help ease the pain for some of you out there taking your lumps working the API into your applications.

Eran starts with a look at some of the different payment options, express, direct, recurring and mass, and what they're good for. From there, it's off to the code with his tool of choice being curl to make it simpler to make requests with headers, content and fetch the response message. He's put together a little custom function to make it easier to reuse. As an example, he shows how to make an Express Checkout request by grabbing a token and redirecting to the PayPal site for handling.

Aaron McGowan has a new post to his blog that looks at the work he's done interfacing with the Bing Maps API to do some geocoding for Emitter.ca.

One of the key features which was required for Emitter.ca, was the ability to geocode search terms like street addresses, cities, and postal codes, that a user enters so that Emitter.ca could easily return facilities that are nearby. To do this, we leveraged Bing Maps's API for performing the Geocode lookup. Microsoft offers a variety of APIs for allowing your application to interact with Bing Maps, however, for Geocoding search terms, we utilized Bing's SOAP API.

He shares the class he uses to pull the information out of the Bing Maps SOAP response and push the details into the properties of a class. The simpel class made interfacing with the API an easy task and allowed for string-based lookups on just about anywhere (like "Toronto, Ontario").

Ahmed Shreef has a post he's written up about using SOAP services in PHP (specifically in a CakePHP-based application using some Zend Framework libraries) and drops in a helpful hint at the end about getting .NET clients to play nicely with it.

Last week, I was working on implementing a SOAP server for one of our projects at work, this web service was built to be consumed by some other software that is built using .Net . It wasn't that easy and I faced some problems that made me go crazy for some hours and I wanted to share them here with the solutions.

He includes two snippets of code from his application - one is the SoapController that handles the incoming actions and the other is the handler class with a sample "doSomething" method to return an array. This is where the problem lies. .NET doesn't seem to understand the "Array" return type so it was throwing errors. In order to resolve the problem, hehad to tell the Zend library that he wanted to render the result as a type of "Zend_Soap_Wsdl_Strategy_ArrayOfTypeComplex" for the conversion.

On the Ibuildings techPortal there's a new post with the latest episode in their DPCRadio series (as recorded at this past Dutch PHP Conference) - Melanie Rhianna Lewis' talk on web services and consumer devices.

A web service is an API provided by a site that allows a remote application to access data and use functionality without having to 'act like a web browser'. [...] The talk will describe how a web service targeted at consumer devices can be implemented. It will look at the different methods of calling remote functionality such as SOAP, XML-RPC, JSON and restful services. It will also consider the limitations of consumer devices, memory restrictions, communications bandwidth restrictions, and so on that have to be considered when designing a web service aimed at consumer devices. Finally it will have a brief look at how to make a service secure.

You can find the slides for the session here and you can either listen to the episode through the in-page player or buy downloading the mp3 directly.