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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
3 hours 59 min ago
- BASH script to log IPs on public web server
8 hours 26 min ago
12 hours 2 min ago
- Reply to comment | Linux Journal
12 hours 34 min ago
- All the articles you talked
14 hours 58 min ago
- All the articles you talked
15 hours 1 min ago
- All the articles you talked
15 hours 2 min ago
19 hours 27 min ago
- Keeping track of IP address
21 hours 18 min ago
- Roll your own dynamic dns
1 day 2 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?