Federico Viticci has an overview and examples for the latest Workflow for iOS release, which adds more advanced features for calling into web APIs. It looks great:
For those who are only partially familiar with the terminology, this means that Workflow can communicate with the majority of modern services that come with a web API. If you’ve never worked with web APIs before, it’ll take you a few hours of reading and experiments with dictionaries, token authentications, form requests, and file uploads to get the gist of how it works. But, the Workflow team has managed to make what tends to be a visually unintuitive programming task – assembling dictionaries and structuring JSON – as simple and attractive as possible, abstracting many of the complexities that web developers have to deal with in desktop IDEs and command-line tools.
Here’s another nice example of automatically creating GitHub Gists, from Jordan Merrick:
This is a workflow I’ve always wanted to create, and the new API support makes it possible. Gists are great to share small pieces of text information, such as code snippets or scripts. This action extension workflow accepts files of any type (though they must be text-based) and creates a gist using the GitHub API.
Workflow can now take over many web tasks that previously required either writing scripts or depending on hosted solutions like IFTTT and Zapier. Like my workflow for posting photos to my blog, it’s a natural tool for web publishing and microblogging.
I’d also love to see a Mac version of Workflow one day. I do some limited automation on my Mac, but AppleScript and Automator aren’t as easy to use or as well-maintained as Workflow.
In 2014, web app APIs basically look like this:
- JSON or XML API layer for a web site’s content and functionality.
- Potential client developers must register with the web site and get some kind of API key for access.
- OAuth is used to grant access without giving out passwords.
A more cynical view of that last point could be rewritten as: OAuth is used to control and limit access so that the API is inaccessible without approval from the web site.
This all seems fairly normal today. I required an API key for Tweet Marker because that’s just what you did, especially if you wanted to charge or limit an API. But it didn’t always used to be this way — remember when you could hit the Twitter API with just a user’s password? — and it doesn’t have to be this way forever.
For my next web app I’m going to have an API that is more open, requiring no app registration. Instead it will be user-centric, with password tokens that a user can paste into their favorite compatible app for authentication. (My web app doesn’t have traditional passwords at all.)
Not having API keys removes a whole set of complexity: no need to write all the backend code to support managing them, no need for developers to register, no need for me to judge who should get access. Whenever possible, APIs should be nearly as open as the normal web, where Safari and “curl” don’t need to register with a web site just to download its home page. Users are in the best position to know which apps should get access to their account anyway.
If we can loosen APIs, I think it makes the web better. Dave Winer takes it one step further:
“What we really need, and I hope to help make happen, is a network based on open syndication of content. Then there is no one to ask for an API, because there’s no one in charge.”
I’ve been calling my latest project halfway decentralized. I’m still in charge, but just barely.
Mike Ash has been rocking with his weekly Friday Q&As. From the “latest about using private APIs”:http://www.mikeash.com/?page=pyblog/friday-qa-2009-01-02.html:
“Remember that the cost is not just to you, but to your users. If you’re really unlucky the break will be so bad that it’s not even obvious that it’s your fault, and they’ll figure it out only after much head-scratching. Once they do figure it out, they will hate you if your fix doesn’t come really fast.”
My new app (not officially announced yet — more later) currently uses Quick Look as a significant part of the user interface. Quick Look is a private API on 10.5, but my hope was that surely it would be made public by 10.6. If I coded correctly for both cases (I have a 10.6 seed running here I can test against), then I could safely release the product and be reasonably certain that nothing would be break.
I’m now rethinking that, both because it looks increasingly like Quick Look will remain a private API even in Snow Leopard, and because I’ve gotten feedback that it’s not a perfect fit for how I’m using it anyway. At the very least I will turn Quick Look into a secondary option, something that wouldn’t be missed if it went away, and roll my own preview UI to be the default.