Build your own Web Service with PHP and XML-RPC

One of the Internet’s current hot topics is Web Services, introduced by Kevin Yank in his article Web Services Demystified.

If you’ve been following industry news on the subject, you may think this is some high level technology, of interest only to big companies with huge budgets. But if you did, you’d be wrong.

The concepts behind Web Services are remarkably simple, and in this article we’ll be taking a deeper look at what’s involved. Then, with a little help from our good friend PHP, we’ll set up our first Web Service.

We will assume some knowledge of PHP, MySQL and XML, which — if you’re uncertain of — you can quickly pick up from Building your own Database Driven Website using PHP & MySQL and XML – An Introduction.

So here’s what’s on the menu:

The Basics of Web Services: To start with we’ll be quickly reviewing the basic concepts behind Web Services.

Introducing XML-RPC: Next, we’ll introduce you to an XML standard for the exchange of data between systems, and we’ll put it into context with Kevin’s article.

PHP XML-RPC Implementations: Then we’ll review some of the Open Source implementations of XML-RPC in PHP: code you can use to quickly build your own Web Service, or access other Web Services from your site.

Your first Web Service: If you want to get straight down to business, this is the place to be. Here, we’ll take one of the implementations described previously, and build a Web Service for it in PHP.

What you can do with XML-RPC: Wondering what to do next? We’ll give you some ideas for what you could do with XML-RPC and Web Services.

Let’s get started!

THE BASICS OF WEB SERVICES

The first thing to understand about Web Services is they’re not really anything new. If you’ve ever used an RSS Feed to take news from another Website and place it on your own, you’ve already got a good idea of how Web Services work (see Kevin Yank’s article: PHP and XML: Parsing RSS 1.0).

Web Services are about exchanging data between a server and a client, using a standard XML format to "package" requests and data so that both systems can "understand" each other. The server and the client could both be Web servers, or any other electronic device you care to think of.

Network-wise, data exchange in a Web Service typically happens via TCP port 80, using standard HTTP protocol POSTs. Put another way, Web Services operate in basically the same way your browser does when it POSTs an HTML form to a site, and receives a Web page in response. The only real difference is that, instead of HTML, Web Services use XML. And this means Web Services can be available anywhere on the Internet, passing through firewalls the same way viewing a Web page does. The data exchange happens at the packaging layer.

On top of the data exchange, you also need information that describes the interface (or Application Program Interface – API) to the service. This makes the Web Service useful to the rest of the Internet, allowing other developers to develop programs that can access your Web Service. This is called the description layer, and the WSDL (Web Service Description Language) standard that will make this happen is under development.

Above that, there’s information that describes the nature of the service itself (not unlike the HTML-descriptive META tags), so that it can be categorised and found on sites that offer Web Service directories. This is thediscovery layer, which is currently being addressed by the UDDI (Universal Description, Discovery and Integration) standard.

Both the description and discovery layers are simply XML, governed by a particular format that enables relevant information to be found for all Web Services on the Internet.

Perhaps what’s made Web Services a hot topic recently — aside from marketing by the likes of Microsoft and IBM — is the development of these standards. They’ll allow Web Services to be rolled out en masse across the Internet, backed by development tools that’ll make access to them both predictable and easy.

But it should be remembered that everything a Web Service does now, in terms of data exchange, could also have been done 5 or even 10 years ago using the HTTP standard and whichever XML format you chose to use or invent (RSS feeds being a prime example). The "hot news" today is that building and distributing a Web Service is now a lot easier than in the past.

Anyway, if you’re looking for a hype-free news source for the technological development in Web Services, tryXML Hack.

We’ll skip further generalities, but suffice it to say that this article focuses on the packaging layer, i.e. how you build and access a Web Service.

INTRODUCING XML-RPC

In "Web Services Demystified", Kevin looks at a standard called SOAP, which is used to "package" data for exchange between two systems. SOAP is on its way to being the W3C standard for Web Services, and with backing from Microsoft and IBM will probably get the official stamp very soon.

But another standard exists for the same purpose: XML-RPC. It’s been around since 1998, and although it’s not an official W3C standard, is already widely used, and has impressive support in the form of Open Source projects. Developed by Useful Inc. in conjunction with Microsoft, it can be regarded in many ways as the forerunner to SOAP, which hasn’t stopped running quite yet.

As this article will demonstrate, the biggest thing XML-RPC has going for it is simplicity, which is clear from the start when you compare the 1500 word specification with SOAP’s 11,000 word (and growing) bible. The other good news is that XML-RPC is well supported in PHP, along with implementations in just about any other language you could desire.

For a detailed comparison of XML-RPC and SOAP, I’d recommend reading XML-RPC vs. SOAP. In brief, SOAP is intended to fill the gaps in XML-RPC, offering a truly enterprise-level mechanism for the exchange of data between systems. For example, it should be easier to deliver multi-dimensional arrays through SOAP than through XML-RPC. But there’s nothing wrong with using XML-RPC, especially given that it’s a stable standard, while SOAP may undergo further re-definition in the future.

You might wonder whether it’s worth putting the effort into learning about XML-RPC if it’s about to be superseded by another standard. Worry no more: you can easily transform a SOAP request to an XML-RPC request using XSLT, which will allow your XML-RPC to survive in a messy Internet where everyone’s looking for the SOAP (apologies — but one pun had to be made).

So how does XML-RPC work? As you’ll see later in this article, you don’t really need to know too much about it to be able to use it. But there’s plenty of information out there that describes it, and a worthwhile read is XML-RPC for Newbies. We’ll take a quick look at how XML-RPC works now, and then move on to how we can make use of it.

The two main components of an XML-RPC "message" are methods and parameters. Methods correspond loosely to the functions you define in PHP, while parameters correspond to the variables you pass to those functions. Parameters can be one of a number of different types, such as strings, integers and arrays — very similar to the variable types you’re already used to in PHP. In addition, XML-RPC defines other tags for things like error handling, but we’ll leave that explanation to the spec as, for the most part, we’ll never need to worry about them.

An XML-RPC "conversation", between two systems bgins with a request from the XML-RPC client, which the server answers with a response. The request contains a method and perhaps some parameters required by the method. The response replies with parameters that contain the requested data. The process is very much like using a function you’ve defined in a PHP script; you call a function and pass it some variables. The function then responds by returning some variables.