At the Forge - eBay Web Services
Before you can use eBay's Web services, you first must register. I'll now say something I've never had to say before in the history of writing this column: I cannot guarantee the directions I provide here will work. I had an extremely difficult time registering with eBay's developer system, despite spending hours trying to do so, and I worry that many readers of this column will face similar challenges.
The first confusing issue is the fact that eBay has several different computer systems, each with its own user database. The first (www.ebay.com) is the main, regular eBay system, on which you already have a user name and password if you ever have bought or sold something on eBay.
A second system (www.sandbox.ebay.com), known as the sandbox, is where eBay developers can test their applications without having to use up their monthly quota of requests (described in greater detail below) and without having to risk damaging a working on-line store. You can do anything you want inside of the sandbox, including create new users (to simulate interactions with those users), but the database is separate from the main eBay site.
Finally, there is the eBay developer site (developer.ebay.com), which allows access to the APIs, certification of applications and documentation. Access to this site requires a third user name and password.
I suggest that aspiring eBay developers register with all three of these sites—starting with the main eBay site, continuing with the developer site and ending with the sandbox. Technically speaking, you don't need to register with the sandbox if your applications will be used only on the production eBay system. However, I found enough places in which URLs mistakenly took me to the sandbox, rather than the developer site, so obtaining a sandbox login would be a prudent move. Was I sent to the sandbox because it's the same as the developer site? Because of a bug? Because of something that went wrong in my configuration? I wish I could say; I spent a great deal of time trying to figure it out and am simply trying to avoid pain for readers of this article.
Part of the confusion is that the sandbox looks and feels exactly like the regular eBay site. This is largely a good thing, except that it means the only way to distinguish between the sandbox and the usual eBay site is by looking at the URL. Even confirmation e-mail messages from the sandbox were identical to e-mailed notices from the production eBay site.
Once you have all three logins, you need to generate a set of production keys: a developer ID, an application ID and a certificate ID. These IDs uniquely identify you and your application, although the role of each key is not obvious to me. (The eBay documentation indicates that each application has its own key, but I could not figure out how to generate a new set of keys for a separate application.) Each developer may have only one set of such production keys. Although the term application ID implies that there would be a separate key for each application you create, this does not seem to be the case.
If you are going to use eBay's production system, then you need to certify your application. There are two levels of certification. One, known as self-certification, allows you to make up to 10,000 requests to eBay's servers per month. Self-certification, as its name implies, requires that you fill out a short Web-based form describing your application. Upon submitting the form to eBay's server, you are sent an e-mail indicating that your application has been self-certified. This e-mail message contains a link to a URL from which you can pick up your production keys, as well as a code that you must enter to retrieve those keys.
Using this confirmation code, you then return to the eBay developer site, where you enter it. This results in the generation of your three production keys: the devID, appID and certID (sometimes referred to in the documentation as AuthCert).
If you are planning to use XML or SOAP, this is the end of the certification process; your application will need to send these IDs in the HTTP request headers. But we are using REST, which is supposed to simplify things—and although our actual method invocations eventually will be simpler than the XML and SOAP alternatives, we have not quite finished our task if we want to use REST.
This is because REST parameters are passed in the URL, and it would seem that eBay has (rightly) decided that passing the devID, appID and certID parameters would be ugly and unnecessary. To use REST, it is necessary to create a REST token, which creates a new, encoded string based on the three production keys. To generate the REST key, go to the REST token site, at developer.ebay.com/tokentool. Indicate that you want to use the production environment, that you want a REST token, and then enter your three production keys.
Then, if you're like me, you'll get an error message. Try as I might, I couldn't get past an eBay login screen that was displayed each time I tried to generate the REST token. Needless to say, I was quite frustrated by this point, and I began to wonder how (and why) a multibillion-dollar company could make it so difficult for developers to use its API. (In contrast, I was up and running within about 30 minutes after deciding to use the Google, Bloglines and Amazon APIs. The difference couldn't be starker.)
I never really figured out what happened. Perhaps I wasn't logged in to eBay, although I thought I was logged in to all three sites (the main site, sandbox and developer site). It also could be that I was using Firefox, which is known to have problems with the registration. In the end, I used a different browser just so I could get the REST token. There were some messages on the eBay developer forums indicating that other Firefox users were having similar problems. It might have had to do with one of eBay's SSL certificates expiring several months earlier, although I doubt it. It seems to me that the login portion of eBay's site is in need of better quality control.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
|Non-Linux FOSS: .NET?||Apr 13, 2015|
|Designing Foils with XFLR5||Apr 08, 2015|
|diff -u: What's New in Kernel Development||Apr 07, 2015|
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Play for Me, Jarvis
- Non-Linux FOSS: .NET?
- Designing Foils with XFLR5
- Not So Dynamic Updates
- Flexible Access Control with Squid Proxy
- New Products
- New GeekGuide: Beyond Cron
- Users, Permissions and Multitenant Sites