But let’s say you’re not a bad-ass consumer app developer. Imagine you’re a mild-mannered enterprise dev looking to make a solid app for your field sales organization. What does MBaaS do for you? Maybe the right question is what does MBaaS not do for you? Answer: it doesn’t get you access to the one thing you need as an enterprise developer – enterprise data.

Enterprise apps need data like plants need sunlight. It could be customer records, documentation, pricing information, inventory levels or a myriad other things. But that data is stuck in the enterprise, inside of SAP this and SharePoint that and database the other. No amount of simplifying interactions with AWS will get that information into your hands to build the super-compelling apps employees need access to.

Enter mobile middleware like Layer 7’s SecureSpan Mobile Access Gateway. Getting the stuff that’s locked inside the enterprise into the hands of devs is a middleware problem. It’s about information sharing. It’s about opening up but in a very targeted manner. MBaaS has some great ideas for making a mobile developer’s life easier. Enterprise devs want the same benefits but with the added benefit of access to enterprise data. I joined Layer 7 from a prior gig at RIM to help that happen. Stay tuned for details.

At Layer 7, we work with our customers to help them drive real and measurable business results from their APIs. One specific method that has proven successful over time is running software competitions. As a partner with the leading online competition platform, ChallengePost, Layer 7 helps customers create developer challenges that get the desired results.

Within the scope of a hackathon – even one with unlimited Red Bull and experienced developers – time constraints will always force teams to cut corners and deliver prototypes or alpha/beta applications. By taking the idea of a hackathon and stretching it out over weeks or months, API publishers see drastically improved results.

Online challenges give developers the time to write quality code and build their applications from alpha, to beta, to production. Developer challenges also give API publishers more meaningful ways to engage with the participating teams. Meanwhile, offering prizes creates incentives that drive real, committed interest from developers.

I’ll be looking more deeply into the ins and outs of developer competitions on October 4, when I co-present a webinar called Open APIs + Software Competitions = Innovative & Creative Solutions, alongside Brandon Kessler of ChallengePost. Click here if you want to see more details of this event or if you’re interested in registering to attend.

Everyone wants to capture the long-tail developer but, for many carriers and non-carriers alike, developers in dorm rooms don’t generate revenue. Increasingly, the focus of many enterprise API publishers is on internal users, other enterprise customers and even partners. The mass market is great but, for APIs, it doesn’t always pay immediate benefits.

API goals around revenue, reach and retention are often realized faster by programs that expose APIs to internal developers who can turn around new services faster, customers that can build revenue-driving software faster or partners that can expand collaborative channels across mobile and cloud.

No two API consumers are the same, which means publishers need to build diversity into their API strategies from the get-go. But building flexibility without creating complexity can be tricky. And now for the Layer 7 plug…

API platforms like Layer7′s ease the whole diversification thing. Why build different APIs or API versions for different customers when you don’t have to? One of the popular features of the Layer 7 API Management Suite is the way customized versions of an API can be rendered virtually and exposed to target communities of API consumers, at will.

Something to consider – whether you’re a carrier or not!

This may sound like a typical tech conference but REST Fest is hardly that. Taking its cue from OpenSpaces and similar events, REST Fest is organized by attendees, for attendees. For example, one of the days is devoted to everyone hacking on the same general topic. Another is dedicated to short workshops, all presented by selected registrants.

Similarly, all the general session talks are delivered by the attendees themselves. That’s because one of the “rules” of REST Fest is “everyone talks and everyone listens”. When you sign up to join REST Fest, you are expected to deliver at least a five-minute lightning talk – and there are no exceptions!

Notable presenters will include keynote speaker Stu Charlton (former CTO of Elastra), Matt Bishop (Senior Product Architect at Elastic Path), Pat Cappelaere (currently working on NASA’s SensorWeb project), Leonard Richardson (co-author of O’Reilly’s RESTful Web Services), Sam Ramji (Head of Strategy at Apigee) and yours truly.

I feel privileged to be co-chair of REST Fest and I’m pleased to note that Layer 7 is the event’s Head Sponsor this year. Hope to see you there!

APIs targeting mobile applications should pay special attention to improving call latency, as mobile apps are often used in bandwidth-constrained situations (e.g. using a mobile app on your smartphone connected to an airport wifi). One should set aggressive targets for these latencies, in order to maintain a positive user experience. Although UX specialists have many tricks up their sleeves, they can’t hide a 10-second API response time. Can your API always respond in 100ms or less under bad connections? Better?

Layer 7′s Gateways have built-in compression of REST API traffic using gzip compression. Most client-side frameworks also have built-in support for this kind of encoding. The compression is initiated by the requesting application, simply by adding the following HTTP header to its requests:

accept-encoding: gzip

iOS sample:
…
[urlReq setValue:@"gzip" forHTTPHeaderField:@"Accept-Encoding"]
…

Android sample:
…
URL url = new URL(urlString);
HttpsURLConnection  conn =
(HttpsURLConnection)url.openConnection();
conn.setRequestProperty(“accept-encoding”, “gzip”);
…

JavaScript sample:
…
ajax=new XMLHttpRequest();
ajax.setRequestHeaders(‘accept-encoding’,'gzip’);
…

Any API traffic flowing through theLayer 7′s  SecureSpan API Proxy or SecureSpan Mobile Access Gateway automatically benefits from this compression.

Although the reduced-latency benefit of gzip encoding resources is more pronounced for larger resources and low-bandwidth networks, the compression tradeoff on the client side is negligible. API providers and mobile application developers should consider adopting this mode by default.

In addition to response compression, Layer 7 Gateways also support gzip encoding for request messages. This also provides reduction of latency on the client side when requests contain compressible payloads. For example, consider an HTTP PUT with content-type=application/json. The client application declares the compressed content using the content-encoding http header as part of the request.

PUT /aresource
Content-Type: application/json
Content-Encoding: gzip

[gzip encoded]{
‘a’: ‘large and complex json here’
}[gzip encoded]

When a Layer 7 Gateway detects that an API requester declares this “preemptive” compression, it will not only automatically decompress the request at the perimeter but also compress the response using the same mechanism by default (if the response has a payload).

200 OK
Content-Type: application/json
Content-Encoding: gzip

[compressed response]

Firstly, I’m excited to be working with our new API Evangelist, Alex Gaber. He has a wealth of experience working with developer communities and he’s ready to answer questions and discuss strategies around developer community building. When it comes to this sort of thing,  Alex is the man. In fact, this weekend he’s onsite at Hack Denver, helping API publishers with their open APIs.

Secondly, I think it’s going to be a great chance for our API publishing audience to learn some really valuable lessons that may help them develop new business partnerships and revenue streams. And we’ll ride the momentum of our last Tech Talk, which had great attendance and – most importantly – excellent contributions from the audience.

Our aim with these Tech Talks is to create an informal channel for engaging with API experts in a live, interactive way. With that in mind, start thinking about any questions you might want to ask Alex, be sure to add Building a Developer Ecosystem to your calendar and join us on August 21 for another great Tech Talk.

On the day of the event, join on Livestream or Facebook:
»  livestream.com/layer7live
»  facebook.com/layer7

Tech Talk Tuesday: Building a Developer Ecosystem
Tuesday, August 21
9am PDT | 12pm EDT | 5pm BST

Submit your questions:
Tweet using the tag #Layer7Live
Email techtalk@layer7.com
Check-in & Chat through Facebook

Therefore, I had to do all the things an active developer regularly has to do (coding, debugging, testing etc.) from a device that has no appreciable hard-drive space and does not allow the installation of any customer software. In essence, I was on a strict diet of browser-based and plug-in based tools and services reachable via an Internet connection.

In relatively short order I was able to find browser-based editors (even ones that support line-by-line server-side debugging!), tools for managing data stores and code repositories. Furthermore, I was able to post test scripts for execution/review and even deploy my projects to a wide range of server providers – all from my browser.

Along the way, I discovered that I had an easier time collaborating online with colleagues in other locations and was better able to take advantage of the most recent releases of new services and tools (since there was no “install” or “update” I had to manage). And – of course – I was more mobile in the process.

Not all programming languages, runtime environments and server profiles are represented in the cloud. And there are still many details to work out in order to make assembling a full-featured “cloud tool chain” easy, reliable and cost effective. Nevertheless, I can see that it is a possibility and I have met people who are working to make that possibility a reality.

My advice to developers would be: Conduct your own experiments; try out your own “cloud-only diet” and see what you learn. Even if you decide that not all the pieces you need are available, you may still discover there are ways to leverage cloud-based tooling to reduce barriers, add flexibility and increase productivity in various aspects of your development efforts.

I’ll be exploring these issues in greater depth when I present a talk titled Programming with the OSS “Cloud Stack” at the CloudDevelop show in Columbus, OH on August 3.

We’re very excited to be welcoming Mike Amundsen, Layer 7′s Principal API Architect, back to the Tech Talk studio. He’s ready to take on questions and discuss hypermedia APIs, a subject he literally wrote the book on.

• What makes a hypermedia API different from other API types?
• How is designing one different from designing any other form of API?
• What are the benefits or complications for the publisher and the developer?

These are just a few of the questions that arise when thinking about designing hypermedia APIs. Now’s the time to get your thinking caps on and start formulating the questions you want to ask Mike on his specialist subject.

Make sure you click Add to Calendar to get the full event details and a reminder on the day.

On the day of the event, join on Livestream or Facebook:
»  livestream.com/layer7live
»  facebook.com/layer7

Submit your questions:

• Tweet using the tag #Layer7Live
• Email techtalk@layer7.com
• Check in & Chat through Facebook

That’s why the Layer 7 API Portal – which is designed to help organizations onboard, educate and manage developers – is one of the cornerstones of our API Management Suite.

The world of Web, mobile and cloud API publishing is growing and changing at an incredible rate right now, so we’re constantly working hard to expand and refine our line of API-focused products. With all that in mind – and hot on the heels of our SecureSpan Mobile Access Gateway – we’re very excited to announce version 2.1 of the Portal.

With the developer management needs of API publishers constantly evolving, we’ve added a range of new functionality to the Portal, including:

• Advanced analytic reports
• More granular privacy controls
• Enhanced lifecycle management features
• New customization options for the content management system

We’re exhibiting at Mobile+Web DevCon in San Francisco this week. If you’re at the show and you’d like to learn more about this new API Portal release, please stop by our booth.

Answer: Neither —  they are really only useful as a whole. A client without a server is usually little more than an non-functional wire frame and a server without a client is simply unrealized potential. Bring them together though and you have something of lasting value. So, neither matters more and each actually matters a lot less than half.

In the API world, this is an easy point to miss. The server side always wields disproportionate power by virtue of controlling the API to its services and this can easily foster an arrogance about the server’s place in the world. This effect is nicely illustrated by Twitter’s recent missteps around developer management.

The problems for Twitter all began with a blog entry. Blogs are the mouthpiece of the platform. Tucked away within an interesting entry about Twitter Cards and the potential to run applications within tweets (something that is genuinely exciting), can be found a restatement of an early warning to developers:

“(D)evelopers should not ‘build client apps that mimic or reproduce the mainstream Twitter consumer client experience.’”

Ominous stuff indeed. This was quickly picked up on by Nick Bilton writing in the New York Times Bits blog, who pointed out that the real problem is that Twitter just isn’t very good at writing client-side apps that leverage its own API. Stifling competition by leveraging the API power card can only alienate developers — and by extension the public, who are left with a single vendor solution. Suddenly, it feels like the 1980s all over again.

This ignited a firestorm of concern that was well summarized by Adam Green on ProgrammableWeb. Green acknowledged that API change is inevitable but pointed out that this is something that can be managed effectively — which is not what Twitter is doing right now.

The irony of the whole thing is that, in the past, by exercising its power position, Twitter has actually made great contributions to the API community. In mid 2010, Twitter cut off basic authentication to APIs in favor of OAuth, a drop-dead event that became known as the OAuthcalypse. Hyperbole aside, in terms of actual impact on the populace, this cut over made even Y2K look like the end of days. Given a tractable challenge, developers cope, which is really Green’s point.

What is important to realize is that API Management isn’t technical but social. Win the community over and they will move mountains. Piss them off and they will leave in droves for the next paying gig.

The thing I always remind people is that as a trend, APIs are not about technology; they are a strategy. Truth is, the technology is pretty easy — and that’s the real secret to API’s success. You see, the communications are never the thing; the app is the thing (and that is what WS-* missed). Maintaining simplicity and a low barrier to entry counts for everything because it means you can get on with building real apps.

Now, I can give you the very best infrastructure and tools to facilitate API community. But how you manage this community… Well, that is where the real work begins and — in the end — it’s all a lot less deterministic than we technologists like to admit. People are hard to manage but communities are even harder.

If there is a lesson here, it is that APIs are really about potential and that potential can only be realized when you have two sides — client and server — fully engaged. Mess this one up and you’re left with just a bunch of unused interfaces.