Archive for the ‘APIs’ Category

File Under: APIs, HTML5, Web Standards
Dec
4
2012

BBC Taps the Past to Showcase the Future of Web Audio

By

Mixing old school tape loops with the BBC’s Web Audio API demo. Image: Screenshot/Webmonkey

HTML5 offers developers new ways to display and work with both audio and video on the web. The HTML5 <video> element tends to get more attention, but the HTML5 audio element is equally revolutionary, perhaps even more so thanks to the work-in-progress Web Audio API (currently in the draft stages).

Developers at the BBC recently set out to push the limits of what you can do with HTML5 <audio> and the Web Audio API. The result is a new audio playground site that recreates the sounds of the BBC Radiophonic Workshop using the Web Audio API. Note that right now only WebKit browsers support the Web Audio API. (Firefox supports the older, deprecated, Audio Data API, but plans to ship support for Web Audio in 2013.)

The BBC’s Radiophonic Workshop project is one part cool demo, one part tutorial. It’s fun to play around with, sure, but another reason behind the experiment is to document how to use <audio> and the Web Audio API. The developers also wanted to put the API through some real-world use cases, to see if there are any limitations that could be addressed before the Web Audio API becomes an official standard.

Each of the four demos has a thorough code walk-through showing exactly how it works and which elements of the Web Audio API are being used. There are a couple of dependencies, namely JQuery and Backbone.js, but most of the code is working directly with the Web Audio API.

If you’ve ever wanted to explore the Web Audio API, these demos make a great introduction to how everything works. For more background on the project, see the BBC’s Research and Development blog.

So far the code doesn’t seem to be available through the BBC’s R&D GitHub account. You can always copy and paste from the demo site, but it would be nice if it was available for easy forking and experimentation.

Tags: , ,
File Under: APIs, Backend, Web Services
Nov
29
2012

Google Drive’s New ‘Site Publishing’ Takes on Amazon, Dropbox

By

Google’s demo site, served entirely by Google Drive. Image: Screenshot/Webmonkey

Google has unveiled a new feature dubbed “site publishing” for the company’s Drive cloud hosting service. Drive’s new site publishing is somewhere between a full-featured static file hosting service like Amazon S3 and Dropbox’s public folders, which can make hosted files available on the web.

Google has set up a simple demo site served entirely from Google Drive to give you an idea of what’s possible with the site publishing feature. Essentially site publishing gives your public folders a URL on the web — anything you drop in that folder can then be referenced relative to the root URL. It’s unclear from the announcement how these new features fit with Google’s existing answer to Amazon S3, Google Cloud Storage.

The API behind site publishing works a lot like what you’ll find in Amazon’s S3 offering. If you use the Drive API’s files.insert method to upload a file to Drive, it will return a webViewLink attribute, something like https://googledrive.com/host/A1B2C3D4E5F6G7H8J. That ugly, but functional URL becomes the base URL for your content. So, if you uploaded a folder named images, with a file named kittens.jpg, you could access it on the web at https://googledrive.com/host/A1B2C3D4E5F6G7H8J/images/kittens.jpg

There’s one drawback though, Drive’s site publishing doesn’t appear to support custom domains, which means it works fine for assets like images, CSS or JavaScript, but unless you don’t mind serving your site from some funky URLs, it’s probably not the best choice for hosting an entire site.

There are already numerous static file hosting solutions on the web including Dropbox and Amazon’s S3, as well as whole publishing systems that use Dropbox and S3 to host files, but for those who would prefer a Google-based solution, now you have it.

For more details on the new API see the Google Apps Developer Blog and be sure to read through the Drive SDK docs. If you need help, Google is answering questions over on Stack Overflow.

Tags: , ,
File Under: APIs, Location
Sep
18
2012

New Amazon Maps API Challenges Google

By

Image: Amazon.

Amazon is once again jumping into the online mapping fray with a new Maps API for Android developers building apps for the Kindle Fire and Kindle Fire HD tablets. While it’s just for Android developers at the moment, several of Amazon’s other APIs have started small and grown into web-wide offerings.

Unfortunately, unlike like Amazon’s long since shuttered A9 map tools, it doesn’t appear to actually be using Amazon data. In fact, the new Maps API is really just an API wrapper around Nokia’s maps and geocoding interface, which also now powers the maps on Flickr.com.

Like Apple’s iOS 6, Foursquare and other high-profile Google Maps defectors, the Amazon Maps API seems to exist primarily as an option for those who’d like to avoid the Google Maps API. Amazon’s announcement touts the API’s “simple migration path for developers who are already using the native Google Maps API on Android,” but neglects to mention any benefits developers might gain from dropping Google’s API.

In this early beta offering Amazon’s Maps API doesn’t have any features above and beyond Google’s API. The Amazon Maps API offers most of the same features you’ll find in the Google Maps API, including street maps, satellite images and custom overlays for landmarks and points of interest, but lacks street-view imagery, terrain maps and other features found in Google’s offering.

If you’d like to give the Amazon Maps API a try in your Android app, head on over to Amazon’s new Maps API site to request access.

Tags:
File Under: APIs
Sep
13
2012

Rails App Details Apple’s New ‘Passbook’ Web Service

By

Apple’s new Passbook app. Image: Apple.

Apple’s recent iPhone announcement contained one tidbit of interest for web developers — Passbook.

Passbook is a new app coming in iOS 6 that collects your boarding passes, movie tickets, retail coupons, loyalty cards, and more and stores them all in one place. Checking in for a flight? Just pull up Passbook and you’re done. Ditto for redeeming coupons, getting movie tickets and so on.

What makes Passbook interesting for web developers is that on the back end there’s a REST-style API for sending updates. The API allows developers to register web services which can then automatically update content on the “pass,” as Passbook entries are known. For example, you could update a coupon or add more credit to a pass based on a transaction on your website.

Passbook communication happens through Apple’s new PassKit web service. The PassKit API offers endpoints to get the latest version of a pass, control push notifications for a pass and query for passes registered for a device.

As with all things Apple, you’ll need a developer account to build anything, but if you’d like to get some idea of how the web service end of Passbook works, check out Mattt Thompson’s passbook_rails_example. Thompson has put together a basic Rails app that shows how to work with Passbook, including how to register devices, get the latest version of a pass, get serial numbers for passes on a device and unregister a device.

For more details, head on over to GitHub.

Tags: ,
File Under: APIs, JavaScript, Web Basics
Sep
11
2012

RSS in JSON, for Real?

By

Photo: Kevin Conboy/Flickr

A short while ago Twitter said they were going to move to JSON over XML, without much explanation other than they like JSON and not XML so much these days, etc. I’m a big believer that everyone has the right to support whatever they want when they want for whatever reason, whether they say the truth or not. Because of that belief, I take with a grain of salt every bit of support for every format and protocol. I assume that just because someone supports it today doesn’t tell you for sure that they will support it tomorrow. Though the penalty is usually pretty high for removing support for interfaces people depend on. They tend to remember it next time you ask for their trust. All that is fair game too.

So anyway, this got me thinking again about the possibility that JSON might take over from XML. What then? Should we give up all the interop we get from RSS just because it uses XML and not JSON? And it’s because of all that interop that that day will never come. A transition may happen over a long period of time, and before it’s complete there will be something after JSON. Because smart people see that, they tend to be conservative about switching just for the sake of switching. It’s why the web, which is entirely an XML application, will keep XML support everywhere for the forseeable future.

In other words, I’d bet with virtual 100 percent certainty that it’s safe to keep producing XML-based RSS feeds.

But people like JSON, there’s no denying that. And a JSONified RSS can totally co-exist with the original XML. So let’s have RSS in JSON? That’s a question that seems worth asking about, at this time.

Turns out it is a very straightforward thing to do. I of course have an RSS feed for Scripting News, the blog you’re reading right now. I wrote a script that maintains JSON and JSONP versions of the same content, automatically. When the RSS is built so are the JSON formats.

http://scripting.com/rss.json and http://scripting.com/rss.js

I learned a long time ago to embrace change. It’s why there is a RSS today that is derived from the RSS that Netscape shipped in 1999 and has features of my scriptingNews format shipped in 1997. If the world wants to go to JSON, help it get there in a way that benefits from all we learned in the evolution of RSS from 1997 through 2002. It’s stood up pretty well over the years. And there’s wide support for it, and lots of understanding of how it works. If there is to be a JSON-based syndication standard, we can cut years off the development process by simply accommodating it.

So I put together an invitation to discuss this.

http://rssjs.org/

If you find this interesting, give it some thought, and if you have something to say, write a blog post of your own, or write a comment on that page. Obviously there’s no moderation for what goes on your blog, but there will be moderation of the comments. Be aware of that. One feature of the past are personal attacks which are totally pointless and subtract from the discourse, and we should not carry that practice forward. That’s why the moderation. :-)

Otherwise, I totally look forward to hearing what people think.

Thanks…

This post first appeared on Scripting News.

Dave Winer, a former researcher at NYU and Harvard, pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software. A former contributing editor at Wired magazine, Dave won the Wired Tech Renegade award in 2001.
Follow @davewiner on Twitter.
Tags: ,
« OLDER POSTS