Open 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.

As the leader of Layer 7’s North American API Architecture & Design Practice, I often get asked to review Web solutions. Rarely do people ask me if the implementation is appropriate for the intended use. Instead they want to know if the work fits a label invented over a decade ago by a PhD candidate in his dissertation. They want to know if what they’ve come up with is “RESTful”.

Essentially, REST (representational state transfer) 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”.

The set of architectural constraints Fielding defined in his dissertation remain the key criteria by which we judge whether or not a service is RESTful. Back in 2000, Fielding did a very good job of defining the six primary constraints: client-server; stateless; cache; uniform interface; layered system; code-on-demand.

However, REST is also defined by four “interface constraints” that are only partially defined in the dissertation: identification of resources; manipulation of resources through representations; self-descriptive messages; hypermedia as the engine of application state. In particular, the definitions of self-descriptive messages and hypermedia are still debated.

Assuming you can decide on clear definitions of all 10 constraints, all that remains is to identify each of them within the target design. If the implementation does not exhibit all ten (well nine, since code-on-demand is optional), then it is not RESTful. This last step is not difficult. It is the previous step (agreeing on definitions) that causes problems.

Still not sure if your service is RESTful? Well, I originally published this post, in expanded form, on my personal blog. If you want to dig deeper, take a look over there.

This 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!

Over 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!

In the previous blog post in this series (Using WebSockets – Part 1: Minding the Gates), Ronnie Mitra talked about the promise of the WebSocket protocol, as well as some security aspects. In this post, I’ll talk about some of the details of the protocol and what they mean for those planning their own WS implementations.

The first thing to keep in mind is that WebSocket is a high-level protocol with its own registered schemes (WS: and WSS:). The specification describes it as: “… intended to be as close to just exposing raw TCP to script as possible.” This is very different from HTTP, which is “…  an application-level protocol for distributed, collaborative, hypermedia information systems.”

That’s good and bad news. It means you have almost the full range of TCP at your disposal. It also means you have none of the established constraints and conventions of the more detailed and focused HTTP specification. This has implications for both design and implementation of WS solutions.

Originally designed with Web browsers in mind, the WS protocol can also be implemented for mobile, desktop, and other stand-alone clients. There are quite a few checks and balances in the specification in order to make it easy (and safe) for browsers to switch from HTTP to WS conversations, all from JavaScript.

However, since many installed browsers do not yet natively support the WS protocol, these checks and balances are not always employed. Instead, WebSockets implementations often take advantage of browser workarounds and fallbacks, in order to support the real-time communications the WS protocol was designed to provide.

It’s also important to remember the specification states: “While this protocol is intended to be used by scripts in web pages, it can also be used directly by hosts [which] can therefore send fake ‘Origin’ header fields, misleading the server.” Implementations that will receive requests from non-browser clients should include additional checks to ensure these requests are valid.

Finally, as the protocol was designed to support real-time communications, it won’t scale in the same way HTTP does. Since the server will keep connections open to all active clients in order to track and broadcast content, servers will need to maintain (or persist) information about each connected client (including knowing when that client is no longer connected!)

If your current HTTP implementations rely on server-based session state, you may not see much difference in the scaling limits of WS. Remember though, the Web’s scaling success is largely based on HTTP’s ability to handle client requests without requiring server-persisted data. Also, some software and implementation patterns designed for HTTP will not work for WS.

Implementing WS is not for the faint-of-heart: it’s not yet widely supported on installed browsers; it uses a different implementation model; it takes more effort/resources to scale it up as services become popular. However, there are some good libraries for coding WS solutions and it can be relatively easy to get started on implementing WebSockets.

But be ready. If you experience great success, you’re likely to have a challenge on your hands!