September 25th, 2012

Do You Need MBaaS to be a Mobile Bad Ass Developer?

MBaaSSimple answer: no. But if you’re a developer building the next great consumer app in a hurry, it probably won’t hurt. MBaaS (“mobile backend as a service”) solves some pretty prickly problems for the start-up developer. MBaaS offerings like Appcelerator, CloudMine, FeedHenry and StackMob deliver the basic components for storage, messaging, notification, user management and so forth that mobile developers need, making it easy for developers to set up and operate the backend for their applications.

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.

September 24th, 2012

Upcoming Webinar: Open APIs + Software Competitions = Innovative & Creative Solutions featuring ChallengePost

Layer 7 Challenge Post WebinarOpen API publishers often find themselves testing different strategies for promoting their APIs to developers. Hackathons represent a quick and easy way to get publicity and traction but API publishers often find the effects to be short-lived, with few meaningful mobile apps or Web mash-ups actually getting built.

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.

September 11th, 2012

Dispatches from Rome: Different Strokes for Different Folks Applies to APIs Too

SDP Global Summit 2012This week, I’m at the SDP Global Summit in Rome, which is focused on API publishing for telecom carriers. One of the comments I’m repeatedly hearing from speakers with carrier organizations is that they want to support different communities of API consumers without complicating their API publishing strategies.

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!

September 6th, 2012

REST Fest 2012 in Greenville, SC

REST Fest 2012Over the weekend of September 13-15, a small band of Web architects and developers will – for the third year in a row – descend upon the town of Greenville, SC. They’ll be getting together to catch up on the events of the past year, share stories about recent projects and contemplate the future of Web and mobile applications.

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!

August 28th, 2012

Mobile API Best Practice: Traffic Compression

Mobile API Traffic CompressionDespite how simple it is to support, compressing API traffic is an often-overlooked optimization. In situations where an API returns verbose resources, compressing the payload is a great way to reduce latencies. JSON and XML are highly compressible formats, for example.

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]