Web services allow you to exchange information over HTTP using XML. When you want to find out the weather forecast for New York City, the current stock price of IBM, or the cost of a flat screen TV on eBay, you can write a short script to gather that data in a format you can easily manipulate. From a developer's perspective, it's as if you're calling a local function that returns a value.
The key behind web services is platform-independent communication. Your PHP script running on Linux can talk to someone else's IIS server on a Windows box using ASP without any communication problems. Likewise, you can talk to a box running Solaris, Apache, and JSP using the same sets of tools and interfaces.
There are two major types of web services: REST and SOAP. A REST request is relatively straightforward, as they involve making an HTTP request of a server and processing an XML document that's returned as the response. Since most developers are familiar with HTTP and XML, the learning curve for REST is short and shallow.
The one downside to REST is that beyond these two conventions, there's not much in terms of standards as to how data should be passed in or returned. Every site is free to use what it feels is the best. While this is not a problem for small services, if not designed properly, this can cause complexity when a service grows.
Still, REST is a very popular format and its simplicity is a key factor in its success. Recipe 14.1 covers making REST requests.
The other popular web services format is SOAP, which is a W3C standard for passing messages across the network and calling functions on remote computers. SOAP provides developers with many options; however, this flexibility comes at a price. SOAP is quite complex, and the full specification is large and growing.
Ideally, SOAP should make things simpler. Communication between services is handled by a client and server that automatically serialize data types from one language to another. Therefore, you can pass and retrieve complex data structures back and forth without needing to worry about interoperability woes.
When this occurs, things are absolutely great and everything just works. However, because of the abstraction layer that SOAP places over communication, it can be difficult to debug when you run into a problem. Since you're not familiar with the underlying XML, it can take a while to get up to speed just to diagnose the issue.
PHP 5 bundles a SOAP extension, ext/soap. Right now, this extension implements most, but not all, of SOAP 1.2. Overall, this implementation is as good or better than other PHP SOAP toolkits, but it's possible that you'll find an area or two that are deal breakers.
It's enabled by default as of PHP 5.1, but you can enable SOAP support on earlier versions by adding --enable-soap to your PHP configure line. The only external library you need is libxml2, which is the same requirement for any of PHP 5's XML extensions.
SOAP is the subject of Recipes 14.2 to 14.11.
Complete details on SOAP are available on the W3 web site at http://www.w3.org/2000/xp/Group/ and in Programming Web Services with SOAP by James Snell, Doug Tidwell, and Pavel Kulchenko (O'Reilly).
Beyond REST and SOAP, there's one other web services format that's relatively common, XML-RPC. XML-RPC is similar in spirit to SOAP, as it also converts native data into a language-netural format that you can pass into functions and receive replies. However, XML-RPC is far less complex than SOAP.
This is a great benefit when everything you need to do fits within the feature set of XML-RPC, but will cause issues when you try to break out of the box. The XML-RPC specification is not being actively worked on, so if you can't make it work, you'll need to switch to using REST or SOAP instead.
XML-RPC is the subject of Recipes 14.12 and 14.13.