Just circling back here (hoping someone can help me with my coverage). Given how the endpoint required no authentication (no uid/pwd, key, or token), and therefore, Yahoo had no idea what developers were using it, how did you (speaking to developers here) expect to be notified of the API's retirement?
I'm writing an article about this... Questions to anybody that knows:
1. it looks like this was just a CSV download. Was any form of authentication (even just a Yahoo login) required to download the CSV? I'm just trying to figure out how, if Yahoo actually thought of issuing a warning, it would have known who to send it too or how to get news of the shutdown circulated to the right people.
2. If it was a CSV download, how up to date was the data?
3. Does anybody have a sample URI for a filtered version of this CSV request. For example, just two symbols?
Hi all, I was on vacation when this thread popped-up and I'm now just reading through it all and wanted to say that we at ProgrammableWeb strive to be the very best resource for anyone that's searching for APIs to use in their apps. I'll be the first one to say that achieving this objective always presents a challenge as there are many things we'd like to do by tomorrow, but not the unlimited resources I wish I had to make everything (including your suggestions) happen so fast.
Just to be clear, we have recently re-engineered our underlying data model to better reflect the complex state of the API economy. That data model is really at the foundation of all the functionality that our site offers. So, nailing that model has been critically important. For example, many (not all) developers love SDKs and these days, a large percentage of APIs ship with a full complement of SDKs. Our data model makes it easy to go from one to the other. If you land on an API, you can find all the related SDKs (even if they are third party SDKs that don't come from the API provider). If you land on an SDK, you can quickly get back to the "parent" API. I know.. not a big deal... the sort of basic task that MySQL and other RDBMS are made for. But you'd be surprised how, once we enabled this obvious capability, users started to move back and forth between them. There are many more not-so-obvious capabilities that taken together, will result in not only a very robust power search capability (ie: I'll take RESTful Storage APIs that aggregate all the other storage APIs - dropbox, gdrive, box, etc. -- and offer CSV, XML, and JSON-formatted responses), but also a much more powerful alerting service (our most popular feature).
That data model also had to be nailed to enable a great API for APIs which is also on our road map. I could go on, but hopefully, you get the point. We absolutely hear you on the many things we can do better.
Finally, I would like to address the part about ads, tracking, and so forth. Yes, we do have ads. To build our technology, to run a research team that's constantly finding the latest APIs and SDKs and adding them to our directory, etc, we need sources of funding. We have worked hard to ensure that the ads are not what you're seeing elsewhere on the Web.. you know the ones that have pop-ups on top of pop-ups and auto-playing video on top of already playing video content and so on. Our pages are not littered with text ads either. I would love to run a site without ads at all. But knowing that this isn't possible, I hope that you would consider the minimally invasive ad environment as one that isn't following the rest of the pack to do anything to keep you from your task of searching for APIs or reading our great content.
And regarding tracking, I suspect that it's mostly connected with the ads and retargeting (again, both necessities to help subsidize the cost of us running the site). And we use Google Analytics for measuring traffic which may trigger tracking detectors. But we (ProgrammableWeb) are not deliberately tracking you with some nefarious intent. We do very basic stuff like looking to see if people are finding their way from APIs to SDKs and back again to ensure the usability of our site.
We welcome feedback on everything that we're doing and have an open door policy. You can write to the entire team by writing to editor@programmableweb.com or you can write to me directly by writing to david.berlind@programmableweb.com.
Judging by the comments we get on ProgrammableWeb and that I get in inbox, it seems like a toss up with developers that were once loyal to Microsoft. Some are so die hard that if you even suggest the idea of a future whereby Microsoft has challenges, they'd just as soon slit your throat. Others are clearly spotting greener pastures elsewhere and have decided its time to move on. But, while Satya Nadella has the challenge of competing forces to reconcile (budget vs. the long game), he seems to be keeping the best interests of developers in mind, or at least trying to.
There doesn't seem to be any hint of information about an API for this. There are links to API docs for the other two services offered by Webpurify. But not this one.
Amazing conversation that really provokes us to think about who of us has it right? Those of us who are ambitious about creating opportunity, climbing the corporate ladder, etc? Or those of us who consciously decide to opt for autonomy and convenience (potentially undermining the structure of our capitalist system!). I've written a more detailed response and posted it to ProgrammableWeb since any conversation about APIs are so near and dear to our hearts http://www.programmableweb.com/news/do-apis-eliminate-middle...
I see some benefits to the tight coupling between a JS client and the backend (eg: DSL fields), but are those benefits worth having such a tight coupling compared to REST (I realize this isn't called REST, but rather just CRUD).
Wow, this is a great question. Over at ProgrammableWeb, we have seen A LOT of unauthorized APIs turn up over the years. In fact, when we've discovered them and added them to our directory, we are sometimes asked (occasionally threatened) to take down our directory entry. These APIs are sometimes developed via the scrAPI route, while other times a debugger as been used to watch what a native mobile app does, while still other times, the service provider has simply divulged WAY too much in their client-side Javascript. However it was done, I agree there is a moral dilemma.
If I were to make a suggestion, it would be to report it to the company so that they can learn about how to better secure the API from your hack. I think that outweighs the efficacy of publishing the API to the public. But I guess it depends on what you're looking for; notoriety in the hacker community (you can't put that Pandora back in the box) or a reputation for discretion. Either one will get you credibility. Just in different forms.
One additional option would be to write about how you did it as sort of an instructive piece to hackers and service providers alike (perhaps anonymizing the service in the process). If this is something you are interested in doing, I would gladly pay you for the right to publish that article. Let me know.
I and the other editors at ProgrammableWeb.com will gladly consider press releases or even less formal announcements in the way of emails or pointers to blog posts so long as the announcement is relative to our web/mobile developer-focused audience. We can't get to everything, but one of my growing areas of emphasis coming into 2015 is to develop better relationships with our various constituencies and "announcements" are one way we discover new contacts.
Check out Rapido! by Ronnie Mitra. It's a personal project of his and it's not quite ready for production. But he was looking to scratch the same exact itch and developed something himself for "sketching APIs."
