December 20th, 2012

Top 5 Layer 7 Blog Posts from 2012

Written by
 

Top 5 Layer 7 Blog Posts of 2012To follow up on our Top 5 Resources post from last week, here’s a look at the five most popular, most thought-provoking or just-plain-best posts from the Layer 7 blog in 2012. Mainly though, these are just personal favorites and I should note that they’re arranged chronologically (oldest first), not in order or preference.

The Oracle-Versus-Google Verdict Comes Down
June saw a remarkable amount of media coverage focusing on the world of APIs, as the Oracle/Google court case made headlines. Layer 7’s Jaime Ryan was relieved that the ruling stated APIs are not protected by copyright. Jaime said: “By taking a strong stand on the issue… the judge has possibly prevented a whole new round of lawsuits that could have rivaled the still-ongoing Apple/Samsung/Google patent wars.”
Read the full post >>>

Are Open APIs Too Open for Big Business?
In July, Ronnie Mitra took a detailed look at how nervous major social media platforms like Twitter and Facebook were becoming about their open APIs and concluded that “enterprises will need to adapt or risk being unable to reach their customers as the device revolution continues at its explosive pace… Organizations need to think carefully and plan their API strategies in order to find the perfect balance between control and accessibility.”
Read the full post >>>

Why I Still Like OAuth
In the midst the controversy surrounding July’s formalization of OAuth 2.0, Scott Morrison launched a passionate, though qualified, defense of the standard. Scott argued that “sometimes you just have to declare a reasonable victory and deal with the consequences later. OAuth isn’t perfect, nor is it easy. But it’s needed and it’s needed now, so let’s all forget the personality politics and just get it done.”
Read the full post >>>

History Repeats: The Search for Agility & Reuse Through APIs
This September, Dimitri Sirota visited the SDP Global Summit in Rome and noticed how much of the discussion around telecom carriers’ API initiatives echoed the SOA talk of a decade ago. He noted “telco after telco (echoed) the decade-old SOA mantra of abstraction, agility and reuse when talking about their new API initiatives… But if Web APIs are to deliver on the SOA vision of agility and reuse, they will need some of the same plumbing that made Web services work.”
Read the full post >>>

RESTful or Not?
Also in September, Mike Amundsen provided an explanation of the key term “RESTful”, which is so often used in reference to APIs and Web services. Mike explained: “Essentially, REST… is a style. Specifically, it’s a style of network-based software architecture. This style was first defined in 2000 by Roy Fielding. Fielding stated that ‘an architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference’.”
Read the full post >>>

December 19th, 2012

Do You Agree to the Terms & Conditions? Mobile Devices & the Tipping Point of Informed Consent

Written by
 

End-User License AgreementSometimes, I wonder if anyone in the entire history of computing has every bothered to read and consider the contents of a typical end-user license agreement (EULA). Some Product Manager, I suppose (though truthfully, I’m not even sure of this one).

The EULA, however, is important. It’s the foundation of an vital consent ceremony that ends with only one effective choice: pressing OK. This much-maligned step in every software installation is the only real binding between an end user and a provider of software. Out of this agreement emerges a contract between these two parties and it is this contact that serves as a legal framework for interpretation should any issues arise in the relationship.

Therein lies the rub, as the emphasis in a EULA — as in so much of contract law — is on legal formalism at the expense of end-user understanding. These priorities are not necessarily mutually exclusive but as any lawyer will tell you, it’s a lot more work to make them coexist on a more-or-less equal footing.

Mobile devices may provide the forcing function that brings change into this otherwise moribund corner of the software industry. Mobility is hot right now and it is demanding that we rethink a wide span of business processes and technologies. These new demands are going to extend to the traditional EULA and the result could be good for everyone.

Case in point: the New York Times reported recently on a study conducted by the FTC examining privacy in mobile apps for children. The researchers found that parents were not being adequately informed about what private information was being collected and the extent to which it could be shared. Furthermore, many mobile app developers are channeling data into just a few commercial analytics vendors. While this may not sound like too big a deal, it turns out that, in some cases, these data are tagged with unique device identifiers. This means that providers can potentially track behavior across multiple apps, giving them unprecedented visibility into the online habits of our children.

Kid plus privacy equals a lightning rod for controversy but the study is really indicative of a much greater problem in the mobile app industry. Just the previous week, the State of California launched a suit against Delta Airlines alleging the company failed to include a privacy policy in its mobile app, placing it in violation of that state’s 2004 privacy law.

You could argue that there is nothing new about this problem. Desktop applications have the same capacity for collecting information and so pose similar threats to our privacy. The difference is mostly the devil we know. After years of reading about the appalling threats to our privacy on the Internet, we have come to expect these shenanigans and approach the conventional Web guarded and wary. Or we don’t care (see Facebook).

But the phone, well the phone is just… different.  Desktop computers — or even laptops — just aren’t as ever-present as phones. Your phone goes with you everywhere, which makes it both a triumph of technology and a tremendous potential threat to your privacy.

The problem with the phone is that it is the consumer device that isn’t. Apple crossed a chasm with the iPhone, taking the mobile device from constrained (like a blender) to extensible (like a Lego set) without breaking the consumer-orientation of the device. This was a real tour de force — but one with repercussions both good and bad.

The good stuff we live every day — we get to carefully curate our apps to make the phone our own. I can’t imagine traveling without my phone in my pocket. The bad part is we haven’t necessarily recognized the privacy implications of our own actions. Nobody expects to be betrayed by their constant companion but it is this constant companion that poses the greatest threat to our security.

The good news is that the very characteristics that make mobile so popular also promise to bring much needed transparency to the user/app/provider relationship. Consumer-orientation plus small form factor equals a revolution in privacy and security.

Mobile devices tap into a market so vast it dwarfs the one addressed by the humble PC. And this is the market for which consumer protection laws were designed. As we’ve seen in the Delta Airlines case above, the states have a lever and apparently they aren’t afraid to use it.

But legislation is only part of the answer to reconciling the dueling priorities of privacy and consent. The other element working in favour of change is size — and small is definitely better here. The multi-page contract just isn’t going to play well on a four-inch screen. What consumer’s need is a message that is simple, clear and understandable. Fortunately, we can look to the Web for inspiration on how to do this right.

One of the reasons I get excited about the rise of OAuth is because it represents much more than yet another security token (God knows we have enough of those already). OAuth is really about granting consent. It doesn’t try to say anything about the nature of that consent but it does put in the framework to make consent practical.

Coincident with the rise of OAuth on the Web is a movement to make the terms of consent more transparent. This will need to continue as the process moves to the restricted form factor of the mobile phone. I have no doubt that, left to their own devices, most developers would take the easy route and reduce mobile consent to a hyperlink pointing to pages of boilerplate legalese and an OK button. But add in some regulatory expectations of reasonable disclosure and I can see a better future of clear and simple agreements that flourish first on mobile devices but extend to all software.

Here at Layer 7, we are deeply interested in technologies like OAuth and the role these play in a changing the computing landscape. We are also spending lots of time working on mobile because, more than anything, mobile solutions are driving uptake around APIs. When we built our SecureSpan Mobile Access Gateway, we made sure this solution made OAuth simple to deploy and simple to customize. This way, important steps like consent ceremonies can be made clear, unambiguous and — most importantly — compliant with the law.

December 19th, 2012

API Design Tutorial: Pagination

Layer 7 Pagination Tutorial

At the Layer 7 API Academy, we’ve had a few requests from API designers who are seeking strategies for handling large amounts of data in API responses.  Pagination is the most common method for addressing this scenario. Pagination, which is very common on the Web, allows API architects to conserve resources, improve response times and optimize the user experience. It’s a way of splitting up data into “pages” and is used in just about any API that returns collections of data.

I’ve released a short video tutorial titled Use Pagination in Web API Design to introduce the ins and outs of the interface. This video provides a crash course explaining pagination and outlining how to use it effectively in the design of Web APIs. I couldn’t fit all the implementation considerations I wanted in this six-minute tutorial, so watch out for a follow-up video on the subject.

December 18th, 2012

New Mobile eBooks

Layer 7 eBooksAs a Partner Architect at Layer 7, I’m lucky enough to get to interact with some of the best and brightest in the industry. These include software vendors, systems integrators, analysts and thought leaders. When you add in our own experts, we have access to a veritable “who’s who” of the API world.

Recently, we began a series of free eBooks that will distill our communal knowledge into specific, targeted recommendations for dealing with a variety of challenges around APIs – from interface design, to security, to developer engagement. Today, I’m pleased to announce the first two of these, which deal with API exposure for internal mobility projects and for externally-facing open APIs.

First, we have Enterprise on the Go: 5 Essentials for BYOD & Mobile Enablement. This eBook focuses on the challenge of securely exposing internal applications and information assets to mobile employees, either on their own devices (BYOD) or as part of a larger mobility initiative. These five key points for a successful deployment are presented in an easy-to-consume synopsis and then backed up by white papers, webinars and customer case studies. Of particular interest to our enterprise customers are the sections on repurposing existing services and using middleware to optimize for mobile use cases.

Next, we have 5 Ways to Get Top Mobile App Developer Talent for your Open APIs. While not all enterprises have chosen to expose their APIs externally, those that have are faced with the challenge of acquiring a talented community of developers that will build useful mobile apps for the consumer marketplace. However, enterprises can’t simply assume “build it and they will come.” Getting devs onboard requires investment in documentation, branding and community development. This eBook discusses some of the best methods for onboarding and rewarding those developers who provide the most value.

Whether focused on internal or external developers, these eBooks are valuable resources for anyone looking to expose APIs for mobile access to enterprise assets. We welcome your feedback on this format and look forward to continuing the series.

December 14th, 2012

Three Common Web Architecture Styles

Three Common Architecture StylesWhen talking to clients about the architectural details of an implementation, one of the first questions I ask is: “What architectural style is appropriate for this Web solution?” It turns out this question stumps most of my audience. Not many system architects and developers think about it. Instead, they implement solutions using whatever components and frameworks are on hand.

Each technology, service or coding framework exhibits its own “style” for solving a problem. Sometimes we select a system component because it’s familiar (“We use SQL databases because that’s what we’ve always used”). Sometimes we include one because it’s unfamiliar (“We’ve never used Node.js before, let’s try it on this project”). And sometimes we select components based on skill set (“Our team doesn’t have any experience with WebSockets, so let’s just use HTTP instead”). It’s important to step back and get a big picture view when selecting components for a production system that will (hopefully) serve your needs for an extended period of time. And that’s where architectural styles come into play.

Architectural styles set the tone for how components in a system interact, govern the implementation details and establish lines of responsibility and maintenance over time. Setting the style early on and communicating it to the team ahead of time goes a long way toward creating a stable and successful implementation. To help clients get a handle on this topic, I commonly identify three widely varying-styles for Web solutions that people can easily recognize: Tunneling, Objects and Hypermedia.

The Tunneling style is best illustrated by SOAP-based implementations where all requests are “tunneled” through a limited set of components (user management, product services etc.) exposed on the Web. The Object style is one that uses the HTTP CRUD pattern (create-read-update-delete) where domain objects (users, products etc.) are exposed and basic read/write operations are supported for those objects. The Hypermedia style relies on a shared understanding through a message format (media type) that defines both the data elements (users, products etc.) and the possible actions (read, write, filter, report etc.) on those data elements. Each of these styles can be used to implement a solution and each of them has associated benefits and challenges.

This comes up so often that we’ve created a short API Academy video introducing the subject of architectural styles for the Web. Take a look and see if it gives you some ideas for how you can answer this question the next time you are about to embark on a major system implementation: “What architectural style is appropriate for this Web solution?”