It’s shorter than I would have liked, and took longer to write, but it’s nice to have it in my hands.

You can buy it at Amazon.

Strategists everywhere are pushing companies to add APIs to their online properties. Job postings for web developers and architects invariably require experience working with and developing APIs. It comes up in sales meetings, pitches, and casual conversations with industry folks all the time. I’m often left wondering if the term “API” has lost its real meaning and become sort of a stand-in for a handful of fuzzy concepts.

REST APIs are Buzzworthy

In the API chatter, there’s a huge focus on RESTful APIs. Everyone wants a RESTful API. Web developers love REST architectures because the fixed semantics and stateless mapping of resources to URIs lowers the barrier to entry for integration tasks. Devs no longer have to struggle to understand proprietary architectural touches. No WSDL files need to be parsed. No expensive, scale-resistant state-managing caches need to be added. The URI we use in the browser is the same URI our apps use to read JSON or XML, etc. It’s a glorious thing, REST. I absolutely love the style, and preach the benefits to clients whenever possible.

Another thing I peach, when I can, sounds scandalous at first. That message: If you’re adding a REST API to your site, you’re probably doing something wrong. Maybe.

REST APIs are Everywhere. Right?

All the big sites are exposing REST APIs. Twitter has on. Flickr has one. Netflix. Microsoft SharePoint. Everyone, man. Everyone.

But how many are as RESTful as they could be?

If you see the value in a REST API, the last thing you want to do is create something separate from your “main” site or service. Your site is your “API” if you’re being RESTful. If you force a separation or bolt on a separate chunk of URIs meant for API clients you’re probably wasting resources and muddying your domain.

With REST, you should have a distinct, stateless URI for each conceptual resource you provide and should respond to the appropriate HTTP verbs (most commonly, GET, PUT, POST, DELETE, HEAD, TRACE, and OPTIONS).

For example, if you have the concept of a user profile for someone named “TobyJoe” you should have a single URI that represents that profile and that URI should serve any supported format a client application requests. It doesn’t matter what the URI looks like, but there should only be one way of accessing that conceptual resource. You can serve up XML, JSON, HTML, plain text, SVG, or any combination of formats you want. HTTP and the REST style already accommodate for this using certain HTTP request headers. This problem has been solved since the Web existed (basically). And yet, we see a lot of big sites offering two distinct sets of URIs: one for their “site” traffic and one for their “API” traffic.

Really, it shouldn’t matter if someone is requesting the resource at a URI from Safari, Tweetie, cURL, a Flash RIA, or any other HTTP client. The REST style can cover all the content switching and access management you need and you can have a single set of URIs, a single set of semantics, a single engineering team, and a single set of resources to support. The user experience for your third-party development partners will be improved as well.

Twitter: An Easy Example

So why are there two URIs for my Twitter status feed? One for the Twitter-branded HTML (with great microformat support!) at http://twitter.com/tobyjoe and one for XML at http://twitter.com/statuses/user_timeline/tobyjoe.xml?

It’s the same data, in different formats. It’s the same concept: status messages for tobyjoe. Most of the formats Twitter supports are available at the http://twitter.com/statuses/user_timeline/tobyjoe.{EXTENSION} address. Why not the HTML version with the sweet microformats?

Note: I’m sure Twitter has many reasons for this separation. Legacy clients, their ever-changing architecture and unprecedented growth, organizational investment in this style. They have an amazing team over there. I’m only using Twitter as an example because so many developers are familiar with their API.

Still, as both a user and client developer, I’d prefer to see a single URI (or at least one URI template) for each conceptual resource rather than one URI for “people” and one URI template for “machines”.

It’s Not Always That Easy

I know that there are lots of hurdles with development around live products. I don’t discount the operational challenges. I don’t necessarily chastise folks who stray from REST. I would love to see the concept of the RESTful API default to a slightly different meaning that what I see on the web today. Instead of saying, “We are going to add a REST API to our site!” I’d love to see companies say, “We are expanding the choice of representation formats and verbs for some of our URLs!” Not as sexy sounding, but way sexier.

There is a common pattern in the contemporary interactive digital art world: artists’ tools are getting more hardcore under the hood.

A lot of the current stars cut their teeth (and still make their living) on Flash. I was a very active member of a messageboard in the late nineties geared towards web and interactive design and development – a distinction I share with many of the current stars. The messageboard (dreamless.org) is long gone, but most everyone is still in touch, still sharing code and competing or collaborating. It’s nice to a fairly constant community, even if their tools have changed.

A lot of people moved from Flash to Processing – a great Java-based framework and IDE – as their interests moved away from wide distribution (via the Flash player) towards lower-level access to the hardware. Being able to work (almost) directly with OpenGL, for example, was a huge benefit. Processing provides a set of capabilities that is different than that offered by the Flash player, making it a great supplement for digital artists.

These days, the most adventurous (Flash-using) artists are venturing outside of both Flash and Processing. They are leaving their virtual machines behind, diving down into C++, OpenGL, OpenAL, and raw C code. This is a scary place for a lot of digital artists, who often lack CS degrees. Instead of taking the usual CS approach of learning from the hardware up, touching higher level languages (like Java and Actionscript) and virtual machines (like the Java VM or Flash Player) dead last, artists start at the top and move down, stepping into dark, complex, fault-intolerant waters only when they need access to more powerful APIs or direct hardware access. Knowledge is built pragmatically instead of comprehensively – a fact that keeps their perspective unique and their work fresh.

The top toolset for the hardcore digital artists right now is OpenFrameworks. It’s a great C++ library with a passionate community, not at all unlike, or separate from, the Processing and Flash communities. This summer, The Barbarian Group will be announcing a (possibly open) framework with a similar purpose. Flint is a framework for C++ and Objective-C development, allowing cross-platform development that is still platform-specific (if that makes any sense), and includes support for a certain popular mobile device…

These frameworks are vital for the progression of digital artwork because they take very tedious, daunting tasks and boilerplate code and wrap them up in attractive, semantically-appropriate domain-specific languages. In other words, they solve for the user experience of the digital artist. They help minimize painful context switches and free artists up to focus on the art. Instead of trying to remember all the arguments and gotchas with creating double-buffered windows on different operating systems, the artists can spend time creating textures and thinking of new interaction models.

For a framework to succeed, it has to become almost invisible to the coder. This is true of all assistive technologies, and, in my opinion, all technologies should be assistive.

Check out Robert Hodgin’s newest work, using Flint.

Mobile users are often on the move while interacting with their devices. By definition, their environments change almost constantly and often introduce unforeseen obstacles. Mobile conditions can place limits on many user attributes: focus, input precision, network connectivity, available time, personal space, and patience. Yet mobile devices are becoming as robust and powerful as laptops, inspiring tons of new, high-end functionality. The challenge is to reconcile the two factors, creating a helpful user experience that uses the new tech to the benefit of the largest number of users and the detriment of none.

User-centered designers face some interesting questions: How do you design an interface that allows someone to find directions or call a cab while carrying bags of groceries home from the market? How can an interface accommodate limited agility, gloved hands, a jostling subway train, or fat fingers? How do you let users subtly compose, edit, and erase email messages while in a long, boring meeting? (Hint: shake-to-edit or shake-to-delete or shake-to-anything are not very friendly requirements.) How do you model user behavior when the nature of mobile use is unpredictable and endlessly diverse? How can you solve problems as unobtrusively as possible?

I hear questions like these very often these days. Designers and developers who never paid much attention to the usability of their web or desktop applications are suddenly quite concerned about the UX of their mobile applications and mobile-optimized sites. I welcome the new interest in the topic, as I’ve always been a bit UX-obsessed, but I have to wonder about the inspiration. I think I’m witnessing a new empathy for users and a shift from the assumption that users crave every complex, novel, “innovative” idea a designer can throw at them.

Progressive Enhancement to the Rescue

One of the topics covered in my iPhone book is progressive enhancement. For those unfamiliar with progressive enhancement, it is the art of providing baseline value to all users and additional value to those in favorable environments or with extra abilities. A strong, accessible functional baseline is important for all software products and interfaces because we want our products to be user-centric.

Progressive enhancement patterns are familiar to a lot of web designers. I think a lot of folks kind of fudge the topic, though. They meet their stated requirements (such as 508 compliance), but often ignore the art. They provide baseline functionality, but they make it clear it’s only baseline. They passively penalize the audience that can only meet the minimum requirements and focus all elegance, fun, and inspiration on the most capable users.

Building Empathy Through Adversity

I think the growing importance of mobile devices in our everyday lives can give a new perspective on baseline users, perhaps leading to more time spent providing amazing, elegant assistive applications and reducing the importance placed on gimmicks.

Think about it: these days, we are all mobile users. As such, we all face adverse conditions for use. Suddenly, we all understand what it’s like to have external conditions impose limitations on our abilities. We are all handicapped in one subtle way or another as we go about our day. All it takes is a taste of frustration to ignite passion for assistive interfaces.

The applications we truly appreciate in the mobile space are those that enable us to accomplish our tasks no matter what our environment. We can compose emails in the absence of a network connection–they simply send when we are back online. The better Twitter clients and RSS readers store data on the iPhone to provide some value when users aren’t online. The better interfaces allow us to perform tasks with one free finger and minimal attention. They don’t impose gestural abilities on tasks for the sake of novelty. Or, if they do, they treat the novel interaction as an enhancement, allowing us to accomplish the same goals with the tap of a button.

In interactive design, including software and web design, progressive enhancement is often treated as an annoying requirement. Designers can now tap into their own experience using mobile devices to better empathize with users who lack full control of their environment, tools, and body, leading to a new respect for baselines and a shift in attention from the secondary enhancements to the primary use cases.

Wow, long time no write… Typical of me.

I’m wrapping up my newest tech book. Programming the iPhone User Experience will be released by O’Reilly this July.

I spoke at the Web 2.0 Expo (SF) this year on the subject of iPhone UX Anti-Patterns. It was the highest-rated mobile session. Great validation, and I think it’ll go a long way towards squelching the desire to jump off a building every time I have to get on stage.

After the book wraps, I hope to write more often here, on InsideRIA, and for other publications.

Or, I may just drink a lot and lay around.

I guess it was put online as well as in print (in a tough-to-find import mag). I just stumbled across the link tonight.

The formatting doesn’t seem to be there, but the info is clear enough. ;)

I don’t get a chance to write on tech topics as frequently as I’d like. I should work on that.