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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Three More Lessons
- Django Models and Migrations
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- The Controversy Behind Canonical's Intellectual Property Policy
- Secure Server Deployments in Hostile Territory, Part II
- Shashlik - a Tasty New Android Simulator
- Huge Package Overhaul for Debian and Ubuntu
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile