April 10th, 2008

Bad API Docs and The Quest for the UPS API

Can dealing with a difficult API provider be like trying to solve the puzzles in a classic text adventure game? In an amusing blog post entitled The Quest for the UPS API over at Ruby Discoveries and Idioms, the trials and tribulations of dealing with the United Parcel Service API has been parodied as an old-school adventure game. And as any developer who has had to navigate some of the more onerous API sign-up processes or unclear and overly complex documentation can attest, this may seem familiar. As the introduction notes:

I’m inspired by the hoop-jumping UPS (yes, that UPS) requires for developers to begin using their web service APIs. There are NDAs involved, so this is not about the APIs themselves; it is about getting to the point where one can start working with the APIs. It is presented in the format of a text adventure. Pedantic corrections to format are welcome, since it’s been a long time since I’ve played one.

And the game itself? Here’s a snippet that gives you a sense of how it goes:

Welcome to Colossal API Quest! Find the documentation, get authorized to use the development integration environment, and meet the needs of your client to achieve fame and fortune!

• You are in a maze of twisty little passages, all alike. There is a door to the North.
• N
• Welcome to UPS. A GATEKEEPER blocks the door to the North. There are also doors to the East, West, and South.
• talk to the gatekeeper
• “Username and password or register?”
• say register
• “Tell me everything about yourself. Also, what is your UPS account number?”
• N
• “Username and password or register?”
• E
• Welcome to UPS. There are several signs here advertising the wonderful web services UPS provides and pointing to the door to the North. There is also a door to the West.
• N
• The door is locked.
• W
• Welcome to UPS. A GATEKEEPER blocks the door to the North. There are also doors to the East, West, and South.
• W
• Your CLIENT is here. There is a door to the East and to the West.
• talk to the client
• “Is my website ready yet?”
• need UPS help
• What?
• say “need UPS help”
• “You should talk to our UPS contact. She’s in the next room.”
• W
• There is a notepad in an otherwise empty room. There is a door to the East.
• get notepad
• You can’t take that.
• look notepad
• It says, “Sorry, I’m on vacation for the next 6 turns. Please leave a message.”

And this is only the first part of the adventure. API providers might take notes here on what not to do.

Share This

Posted by John Musser as Issues, fun at 2:46 AM | 2 Comments »

March 4th, 2008

Discussing the Pros and Cons of Platforms

Over at ReadWriteWeb, Marshall Kirkpatrick takes a thorough and engaging look at APIs and Developer Platforms: A Discussion on the Pros and Cons. Marshall spoke with a wide variety of people in the industry to pull together a lot of the key ideas and issues in this space. Here are some of the highlights:

• Just offering an API does not guarantee developers will use it. Paul Miller from Talis points out that “Nothing says someone will develop with an API just because you open it. You need the infrastructure, community and technical support around it. [For developers] the API has to do something you want, easier or better than you could it yourself, or bring some other benefits on the side.” If you look at the popularity of APIs in our sample you’ll see that there’s a big difference in adoption across APIs.
• An API can be both a product and a distribution channel. As such it needs to have something to offer the developer. Chris Saad from DataPortability.org said that “if the network has no users, then it will have no developers…the reason dev platforms attract developers is because of their promise of distribution.” For some classes of service-based APIs like Amazon’s S3 or Google Maps this is not an issue, they provide value unto themselves. Mashup developer Taylor McKnight points-out that code reuse and time-to-release are valuable benefits of an API: Why reinvent the wheel when there are wheels available for the taking?” And because this is the end a business relationship, Oren Michels of Mashery and the Business of APIs Conference notes “One opens an API as a business development initiative, and so evaluating its success should be based on how it performs in that context.”
• It takes investment and commitment. Not just creating the API in the first place but supporting it, supporting developers using it, upgrading it, and doing this over the long haul. The major API providers know this and that’s why there are big events now like platform-specific developer days.
• Is it for serious development? The popularity of map mashups and lightweight Facebook apps drive this question. But Esther Schindler, of CXO Media, made the apt point that “ANY development can be lightweight crap. Using APIs isn’t really part of that issue. It’s all a question of good design.”
• The importance of open standards. The best APIs leverage open standards extensively. From the basics like RESTful HTTP and XML to newer ones like JSON and OAuth.

It’s a good overview which in its breadth points out how much discussion and debate there is in this fast moving market as well as how it’s only just getting started.

Share This

Posted by John Musser as Issues, Money at 4:50 PM | No Comments »

January 16th, 2008

USAspending.gov: You Will be Watched

We recently added this new API listing to the US government site USAspending.gov which provides API access to budget data, but we didn’t notice a detail which one of our readers did: that there’s a somewhat intimidating, red-text warning on the homepage that says:

WARNING: This is a United States Federal Government computer system that is “FOR OFFICIAL USE ONLY.” This system is subject to monitoring. Therefore, no expectation of privacy is to be assumed. Individuals found performing unauthorized activities are subject to disciplinary action including criminal prosecution. Click here for more information.

In his blog post Coby Logen points to a variety of potential issues and inconsistencies in the site:

• “For Official Use Only” — This means the information is sensitive, but unclassified. If this is true, then USASpending.gov contains information that should not be released to the public.
• No expectation of privacy — This is in direct conflict with the website’s privacy policy, which opens: “the privacy of USASpending.gov customers is of utmost importance.” It also says that no personally-identifying information is automatically collected when you visit USASpending.gov. The warning and the privacy policy cannot both be correct.
• Unauthorized activities — What exactly would be unauthorized? If the information on the site really is “For official use only”, then it is unauthorized for a private citizen to even access the information.

And later on notes that:

Although there are other ways to get federal budget information, the warning on USASpending.gov is unfortunate, because it is wrong and it violates federal policy. USASpending.gov does not meet the definition of “For Official Use Only”; it contains public information. There is an expectation of privacy; no personally-identifying information is collected from visitors. The warning conflicts with OMB Memoranda, which require each government site to “post clear privacy policies” and adhere to them, because the warning significantly obscures and confuses the site’s privacy policy.

Coby’s post points out a variety of good alternatives including the Sunlight Foundation who provide the same data via the Fedspending.org API as well resources on our Government API Dashboard.

In the meantime, you’ve been warned.

Share This

Posted by John Musser as Gov, Issues, Law at 3:49 AM | 6 Comments »

January 15th, 2008

Hasbro Versus Scrabulous

For the third time in as many weeks a Facebook application is the subject of controversy (the other two being the Facebook Hoax and the Facebook Spyware). This time around the news comes via Fortune’s Josh Quittner who reports that Hasbro, the company behind Scrabble, wants to shut down the popular web site and Facebook app Scrabulous. Scrabulous started in 2006 when two bothers, Jayant and Rajat Agarwalla, created the Scrabble knockoff out of their home in Calcutta, India. It did well that first year but really took off after they ported it to Facebook in June of last year.How popular is it? It’s the 9th most popular Facebook application, has 2.3 million active users and 500K using it every day. And according the Fortune report it has revenues of about $25,000 a month.

Read the rest of “Hasbro Versus Scrabulous” »

Share This

Posted by John Musser as Facebook, Issues, Law, Popular, Social at 12:42 AM | 1 Comment »

January 9th, 2008

French Press and Facebook Mashup Hoax

For the second time in a week a third-party Facebook app is the subject of controversy: this time it’s ePresident, an application for nominating the Facebook’s “worldwide President”. Not a serious app of course, but as reported today by TechCrunch’s Ouriel Ohayon, some of the French press, in a series of escalating misunderstandings, has fallen for this as real. In a nutshell: Facebook user Arash Derambarsh ran for this pretend office, complete with campaign site and pledge for global peace, got over 9000 votes, began getting more and more press coverage that often missed the fake-ness of the whole thing, made it to TV, eventually a Facebook group forms denouncing it, and some of the press catches on, and at this point he’s not available for comment.

Read the rest of “French Press and Facebook Mashup Hoax” »

Share This

Posted by John Musser as Facebook, Issues, Popular, Social at 1:13 PM | 1 Comment »

January 8th, 2008

Google, Facebook Join DataPortability.org

In a promising sign for the future of data portability across platforms, earlier today DataPortability.org Workgroup announced that representatives from Google, Facebook, and Plaxo joined their initative: “We are proud to announce the inclusion of Joseph Smarr (Plaxo), Brad Fitzpatrick (Google) and Benjamin Ling (Facebook) to the DataPortability Workgroup.” For more on the group’s goals, which includes creating a ‘DataPortability Reference Design’, see their philosophy and mission:

Our Philosophy: As users, our identity, photos, videos and other forms of personal data should be discoverable by, and shared between our chosen tools or vendors. We need a DHCP for Identity. A distributed File System for data. The technologies already exist, we simply need a complete reference design to put the pieces together.

Our Mission: To put all existing technologies and initiatives in context to create a reference design for end-to-end Data Portability. And, to promote that design to the developer, vendor and end-user community.

From a technology perspective, they encourage an “Invent Nothing” approach that builds on existing standards like:

• APML
• Microformats
• OpenID
• OAuth
• OPML
• RDF
• RSS

Involvement from some of the biggest names in the business means greater potential for real progress on interoperability. For more on this story see ReadWriteWeb and TechMeme.

Share This

Posted by John Musser as BestPractices, Issues, OpenSocial, Social at 11:59 AM | 3 Comments »

January 7th, 2008

Facebook App Installs Spyware

Anyone who has installed the third party Facebook application “Secret Crush” is at risk of installing spyware according to this report from security firm Fortinet. Apparently the app entices users by saying “one of your friends my have a crush on you” and then once installed it attempts to download the infamous spyware Zango. The malicious widget authors get rewarded with as much as over $1 USD upon each successful installation, according to Zango’s affiliate program rates (note that as of January 4, the widget changed its name from “Secret Crush” to “My Admirer” and as of today WebWare reports that Facebook has disabled the application completely).

Read the rest of “Facebook App Installs Spyware” »

Share This

Posted by John Musser as Facebook, Issues, Popular, Security, Social at 2:32 AM | 12 Comments »

January 4th, 2008

YottaMusic and the Limits of APIs

Web APIs rarely do everything the underlying site or service does. They are typically a defined subset of the total functionality. While understandable from a business strategy and resource perspective, these limits can be frustrating for developers. Sometimes this leads them to find a solution using undocumented APIs, often services used by the UI of the site, that provides them enough functionality to meet their needs (which was essentially the case with the original Google Maps, an undocumented JavaScript API until Paul Rademacher reverse engineered them and built HousingMaps.com).

Read the rest of “YottaMusic and the Limits of APIs” »

Share This

Posted by John Musser as Featured, Issues, Law, Music at 2:31 AM | 1 Comment »

December 20th, 2007

How to Tell if a User is Logged In to Netflix

Even wonder if the sites you log into on a regular basis might inadvertently let any of that information leak? If you want to see a very real, interactive example of just how prevalent this might be, just check-out JavaScript guru Kent Brewster’s series on “How to Tell if a User is Logged In to X”, where “X” is one of the leading online services millions of us use every day. Last week the “X” was Facebook and today “X” is Netflix. Because the examples are live and work with you and your own account they get your attention.

Read the rest of “How to Tell if a User is Logged In to Netflix” »

Share This

Posted by John Musser as Issues, JavaScript, Popular, Security at 12:51 AM | 2 Comments »

December 12th, 2007

MapSpammers Coming to Mashups?

Earlier this year in Beware Mashup Spam we saw how spammers were working on gaming Google Maps via mass uploads and creating questionable or false listings. Well, Search Engine Land’s Mike Blumenthal has just followed-up on his initial report with more in yesterday’s MapSpammers Getting More Sophisticated.

In a nutshell, Mike reports on get rich quick schemes in which the spammer uses post office boxes in any city to “legitimize” themselves and get ranking in Google Maps. The overall scheme is to: “Rent a mailing address with forwarding in every major market near the centroid of the city (UPS is one of many that offer this service); Obtain a domain name for each city with a relevant “location + service” domain; Create a website that returns an optimized “location + service” page for the domain; Enter the businesses in the Google Local Business Center (if you are doing the top 50 metro markets, not such a big deal) note: skip this and the next step if using Yahoo Local; Enter the PIN numbers when they are forwarded to you; Get rich quick.”

Read the rest of “MapSpammers Coming to Mashups?” »

Share This

Posted by John Musser as Google, Issues, Law, Mapping, Money, Popular at 2:15 AM | 4 Comments »