How APIs encourage the separation of content and presentation »

From the dawn of the web, we've been entangling presentation with content. Which is, overall, a big suck. Why? Well, on one hand, it's fine for people to consume. But it's really rude to computers. And computers, after all, are doing all the work to keep the Internet running.

If computers can't easily parse data, they can't do anything meaningful with it. However, once computers can easily disentangle the layers of data, watch out: innovation happens like crazy.

In a series of blog posts I'm going to talk about all the beauty of separating content from presentation. And how that simple idea when amplified with proven, existing design patterns makes things really interesting. Let's start with Twitter as an example...

When you view tweets on twitter.com, you see shared links, hashtags, and @mentions, all of which are clickable. But if you query the Twitter API you get back plain text. Why?

Because Twitter understands the importance of separating the content layer from the presentation layer. Imagine seeing this on a phone:

Ran into <a href="http://twitter.com/shanley">@shanley</a> at <a href="http://twitter.com/#!/search?q=%23sxsw">#sxsw</a>!

… because the SMS app on that old phone didn't understand HTML! Furthermore, when every character counts, like in a 160 character SMS message, markup would end up dominating the content. You shouldn't even assume that the consumer device will even know what to do with it.

So instead, Twitter keeps statuses as simple as possible—text only. This is plain, vanilla content. No markup, just data (well, unless you count the "organic" markup conventions like hashtags and @mentions).

Everything else, all the rest of the CSS and HTML that make up the twitter.com experience—that's the presentation layer. It takes all that content and makes it look good.

APIs, at their most basic, are carriers of content. They are perfectly evolved for getting data from one place to another.

And this is super-important in today's world, where we consume content on multiple devices. One size no longer fits all. There is no single form-factor. Each device offers a different experience of the same content.

This is just one example why APIs are changing the way we develop, by demanding the best-practice approach of separating the content and presentation layers. Modern web applications use the same APIs that their official mobile apps do. And those are the same APIs that get exposed to 3rd party developers who innovate around the edges.

How do content and transactional APIs differ? »

Recently, during one of our our RAW (Rapid API Workshops) with a retail customer, a great question came up - what are the major differences between a content and transactional API?

Probably not a complete list, but in general:

Content APIs are more likely to be open, without sensitive information. Think of a search, media, or mapping API.    While the provider might want to track identity through API keys, these APIs often need no authentication, authorization, or encryption.    Search results may be highly cachable, which might be helpful to support high concurrency for bursts of demand for popular content.    Content APIs are also more likely to need throttling to protect the back-end and quotas to measure consumption - think about that grad student downloading your entire database one API call at a time.   Users might have some tolerance of downtime for free content that can easily be requested again.      Success for content APIs might be measured in terms of usage or engagement. (usage per consumer), so having  API usage analytics might be important.   If you can, make content APIs simple and easy to adopt with standards like REST.   

Transactional APIs  have sensitive data and therefore security needs go beyond identity and developer key level tracking  to include API authentication and authorization.   The data might need encryption and XML or API specific threat protection.    Instead of quotas, the back-end business logic might already contain all the controls you need to measure consumption and monetization.    There is probably no tolerance for downtime or lost transactions.   And of course success for transactional APIs can be measured in existing financial terms.

What's your experience in the difference between content and transactional APis?

Social Mention: API monitoring for social sentiment and alerts »

Warning: don't try Social Mention unless you have 20 minutes - it's addicting.

Social Mention is a social media search platform that aggregates user generated content from across the universe into a single stream of information. 

It analyzes content on terms like apigee (score to the left) or Sam Ramji (screenshot below) and gives you alerts, feeds data and a sentiment scorecard. 

Think Google Alerts but for social media.

Jon, who built Social Mention, uses Apigee to monitor their social media API. We asked him for his insights and experience using Apigee (see below).

What insights into your app or other benefits have you gotten from working with Apigee?

Jon: I would say the best insight is general API usage and error rates.It's great to be able to track usage on an hourly basis and throttle accordingly.

What new Apigee feature would you most like to see from Apigee?

Jon:The ability to track individual users/developers of the api via query string key would be fantastic. Currently, there is no method to tell how many calls each api developer is making.

What mashup, app, or API do you admire?

Jon: I would have to say Twitter's API - it's simple, to the point and it works great. They also don't have restrictive usage policies or rate limit.

We're working hard to get per developer quota enforcement in soon for Jon and the rest of Apigee users that have been asking for this feature on our feedback forum.

Check it out!