On October 19th, Delicious announced that they began support of Yahoo IDs. Unfortunately, that blog post did not mention how this affects using the Delicious API. At the time of writing this, there is no mention at all in the Delicious API docs either.
I am working on integrating Delicious within an existing application, so I decided to create a test account. That’s when I first ran into issues with the Yahoo integration because I was required to go through the ridiculous Yahoo registration process instead of the previous Delicious sign up. After trying a million different usernames and getting the initial CAPTCHA wrong, I had an account and my testing could begin.
My script was not successfully adding a bookmark, so I tested it directly in the browser and realized I couldn’t log in. I tried the username and the firstname.lastname@example.org, but neither worked. I was able to sign in via Yahoo, so I know I was using the right password. I tried my old Delicious account from 2006 that I never associated with Yahoo, and it worked fine.
I ran into a thread of people having the same issue, and then I stumbled across a Yahoo developer forum thread that clued me in on the comments that appeared in the blog post about the integration. A comment from “Chris” revealed a bit more:
Apologies. It looks like our help pages didn’t get updated.
For accounts created with a yahoo ID, you can use pretty much the same api’s except:
1) You need to use OAuth, as per http://developer.yahoo.com/oauth/, with Delicious as a scope
2) use /v2 as the path rather than /v1
3) You can use http rather than https
The problem with this (well, one problem with this) is that it requires two different ways of handling user authentication for the same service. There is currently no indication of best practices (e.g., should the user self-identify as being a standard Delicious account holder vs. a Yahoo account user or do we check submitted IDs to determine which method should be used to access the API?). There is also no indication of whether developers should expect to support two types of IDs forever.
The biggest reason this is so frustrating is because an API change so significant should be planned months in advance with plenty of forewarning for all developers. Instead, the effect to the API isn’t even mentioned in announcement blog post nor is anything posted in the API docs. Disappointed wouldn’t accurately describe how I felt when I stumbled into these issues….