When you talk to many developers today about Web services, you'll get the glassy eyed stare of someone who has dealt with vaporware for far too long. The promise of Web services has indeed eluded developers, and the original promise of Web services still hasn't arrived. However, in the mean time, a number of public Web services have arrived on the scene which offer a tantalizing glimpse of something better, something different. Public Web services are often driven by the need to interact with a profitable Web site faster and more efficiently.

A Little Bit About the Big Three

Three public Web services in use now have made a bid for the hearts and minds of developers. They have one thing in common: they allow programmatic access to a Web site that is already popular. In every case—Google, Amazon, and eBay—developers are looking for ways to interact with the Web site more effectively. That could mean getting information faster or something as esoteric as combining information from multiple sites to create a new result.

After working with all three Web services for a while, I can honestly tell you that the Web services really do help get information faster and let you format the data as you see fit. If you want just text and no graphics, you don't have to display the graphics. Overall, I've found my efficiency has improved without losing any information at all. In fact, I couldn't be happier with the applications that I've been building.

For example, when I go shopping on Amazon now, a click of a button instantly downloads information from Google about the target product. I can see the Amazon reviews, but I can also see articles written about the product. In short, my combined search engine tells me more than either Google or Amazon would alone, and the process is extremely efficient. (To see a public application that uses these two Web services together, check out Authorama. The author even tells you how he combined the two Web services.)

You can use eBay with Google in the same way. Often, the descriptions on eBay leave a little to the imagination. While you can see the product and you have some idea of what it promises, you really necessarily know enough to make a good buying decision. Combining eBay and Google makes it easier to learn more about the item. However, let's say that this is a modern item (not an antique), and it's possible that Amazon also sells it. Add an Amazon search into the mix, and you now know the retail cost of the item and how people feel about it. By combining the three Web services, you can make a very good buying decision.

Don't get the idea that public Web services are limited to the big three. You can find a public Web service to perform just about any task today, such as at the list of public Web services here. One that looks up UPC symbols; another works with ZIP code information. Sure, you might be able to find this information elsewhere, but the fact that you can incorporate the information directly into you application makes these Web services worth their weight in gold.

Examining the eBay Web Services Difference

Most public Web services don't offer much in the way of sensitive information. You pass a request to the Web service and the Web service provides a response. Nothing too secret is ever sent to your application. This isn't a shock with Google Web Services, because Google doesn't buy and sell products. However, even Amazon keeps sensitive information away from the developer. Yes, you can help the user find a product, but once the user has found something to buy, you pass them off to Amazon to complete the transaction. In this way, the user's information remains secret—known only to Amazon.

However, eBay is different.When a developer decides to create a Web services application for eBay, it's suddenly important to consider issues that the developer hasn't had to consider before. For example, when an auction completes, the application now receives valuable user information, including financial information (such as a credit card number). The reason is that eBay acts as a conduit to match buyers and sellers. Consequently, if you want to set up a Web service of your own, one that deals with sensitive information, eBay Web Services is a good model to examine.

The first difference you'll notice is the rather hefty agreement you have to sign. The agreement defines precisely how you must create your application to respect the privacy of your users and to prevent security breaches. Once you agree to the terms of the agreement, you can download the developer kit. This kit includes a number of resources, including a hefty help file, support files, and examples written in a number of languages (including Java, PHP, Visual Basic 6, Visual Basic .NET, Visual C++, and C#). You can learn more about the developer program, including licensing, at http://developer.ebay.com/DevProgram/membership/index.asp.

Aspiring application developers can't work with real data immediately. eBay provides a “sandbox mode” where you create and test your application. Only after the application passes a rigorous certification process can it access the production Web service. This entire process is set up to ensure that your application won't cause problems when used on eBay. It also solves a number of supposedly unsolvable problems that Web service developers have discussed over the years.

Creating a Simple Search

One good way to try a Web service for the first time is to perform some type of search function. Most Web services provide some type of search feature, which usually doesn't do anything other than report on results of the search. From the beginner's point of view, you don't take any chances by modifying valuable data, either on your machine or on a remote server. eBay Web Services is no different; you can perform a number of searches for items that you might want to buy. Listing 1 shows a simple item search. Enter one or more keywords, and eBay returns items that match.

Listing 1: Performing a Simple Search

private void btnSearch_Click(object sender, System.EventArgs e)
{
   ApiSession           Session; // The eBay session.
   GetSearchResultsCall Search;  // Search object.
   IItemFoundCollection Results; // Returned items.
   DataRow              DR;      // Output data.

   // Create a session.
   Session = new ApiSession();

   // Define the sandbox as the call location.
   Session.Url = "https://api.sandbox.ebay.com/ws/api.dll";

   // Add session security information.
   Session.RequestUserId = txtUserID.Text;
   Session.RequestPassword = txtPassword.Text;

   // Add the developer information.
   Session.Developer = txtDevID.Text;
   Session.Application = txtAppID.Text;
   Session.Certificate = txtCertID.Text;

   // Create a search.
   Search = new GetSearchResultsCall(Session);

   // Add the search criteria.
   Search.Query = txtQuery.Text;
   Search.MaxResults = 20;

   // Perform the search.
   Results = Search.GetSearchResults();

   // Clear the current results in the dataset.
   dsOutput.Tables["ItemOut"].Clear();

   // Interpret the results.
   foreach (IItemFound Item in Results)
   {
      // Add a row.
      DR = dsOutput.Tables["ItemOut"].NewRow();

      // Add the data to the row.
      DR["Title"] = Item.Title;
      DR["Current Price"] = Item.CurrentPrice;
      DR["Start Time"] = Item.StartTime;

      // Display the row on screen.
      dsOutput.Tables["ItemOut"].Rows.Add(DR);
   }
}

One reason I really like working with eBay Web Services is that its SDK hides many of the details. You don't have to worry about low level communication, or creating your own XML message. Yes, you can go that route if you want, but you don't have to use those features. This example uses the SDK techniqueÑessentially, a wrapper assembly that makes communication almost invisible. That's right, eBay's SDK support the .NET Framework natively.

The application begins by creating a session. The session is the connection to eBay Web Services. The code assigns a particular URL to the session. In this case, the code assigns the sandbox URL. (There's also a production URL, but you can't access it until your application is certified.)

The next step is to tell eBay about the user. Currently, you can use one of two techniques to describe a user. The first is to supply a username and password, as shown in the code. The second relies on an authentication token. Your application sends the user to eBay to sign in and eBay returns an authentication token you can use in your application. This second method is actually better, because you don't have to handle the username and password in your application.

After you tell eBay about the user, you must provide your own information. When you sign up for the developer program, eBay provides you with three keys, which access the sandbox environment. The first key identifies you as a developer. The second key identifies the application that you're creating (one developer can have more than one application key). The third key is effectively a password for the development environment. Different passwords open different environments.

At this point, the application has all of the required data to communicate with eBay, so the code begins to create the call. This process creates the XML message that the application sends to eBay Web Services. The code begins by defining the call type—a search, in this case. The call must tell eBay what keywords to use, and how many results to return. The response to this request appears in Results.

The Results object is actually a wrapper around an XML message. Again, the eBay SDK hides the details, so you can work directly with the data. The application places the results in a DataSet, which is connect to a DataGrid, as shown in Figure 1.

Figure 1: Custom searches can make using eBay much faster.

The code creates a new row in the DataSet for each item. It fills the row with the item title, current price, and the starting time of the auction. Notice how easy it is to access each of these items. Finally, the code places the new row in the DataSet, which displays the information on screen.

Taking the Long View

For many developers, the promise of Web services has never and will never happen. The corporate business model for Web services is moving slowly, as these large businesses try to deal with difficult issues such as security. However, Web services are becoming a reality. Perhaps it was inevitable that the first real use of Web services would be public, for businesses that have a real stake in making it as easy as possible for developers to create applications for their Web sites.

You can view the current situation in a number of ways. First, public Web services provide you with an opportunity to experiment—to learn how to work with Web services without actually building the needed infrastructure. Second, you can view public Web services as an opportunity. Quite a few companies already sell special eBay Web Services applications that make it easier for their clients to get the items they want. Third, you can use the public Web services as examples of what you want to do. The success of eBay, Google, Amazon, and other Web services illustrates that Web services can work.

Here's one final thought. If your company is already working with Web services and finds that it can't solve the myriad problems involved in maintaining a secure environment, you might want to look at the eBay model. One reason I chose to illustrate this company's product is that they really have solved many of the issues that corporations grapple with today. No, eBay's product isn't perfect, but they have come up with great solutions. You can emulate many of these solutions in your own Web service with a very small investment in time learning how eBay works.

John Mueller is a freelance author and technical editor. He has writing in his blood, having produced 62 books and over 300 articles to date. The topics range from networking to artificial intelligence and from database management to heads down programming. His most recent book is “Mining Amazon Web Services” (Sybex, ISBN: 0782143075). His technical editing skills have helped over 35 authors refine the content of their manuscripts. You can reach John on the Internet at JMueller@mwt.net and his Web site at: http://www.mwt.net/~jmueller/.

Discuss The New Era of Public Web Services   >>> Be the FIRST to comment on this article!

>>> More Techniques Articles          >>> More By John Mueller