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.

Codeception testing framework got significant improvements during last week. The first and the major one is that you don't even need PEAR and Composer to execute tests. Only one file codecept.phar required. This might save your time and mind of your testers.

They've recently added modules for SOAP and REST support, making it easier to define your tests in a more fluid fashion. Included in the post are two examples, one REST and one SOAP. You can find more information about these new testing features over in the tool's documentation.

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.

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.

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.

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.

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.

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.

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.

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").