September 14th, 2012

WebSockets Tech Talk

Written by
 

Ronnie Mitra WebSockets Tech TalkWe aim to keep our Tech Talks relevant and interesting for our viewers. We simply want to provide an open forum to discuss and ask questions about key issues around API Management. So, in keeping with that spirit, our next subject for discussion will be Websockets and the excitement surrounding HTML5′s support for the WebSocket protocol. And I’m excited to have Layer 7 API Architect Ronnie Mitra as my guest for this highly-topical Tech Talk.

The hype around the WebSocket standard, which enables a type of bi-directional, socket-based communication not possible with conventional HTTP, has been steadily increasing over the last two years. As adoption of  WebSockets technology increases, API architects need to understand how they can use the protocol to build great APIs for mobile and Web applications.

In this Tech Talk, Ronnie will be discussing:

  • The ins and outs of the WebSocket protocol
  • The relationship between HTTP-based APIs and WebSockets
  • Use cases that are a great fit for the WebSocket standard
  • The challenges of securing a WebSockets connection

Of course, the discussion won’t be limited to just these topics. We also welcome any and all of your questions and comments. In fact, without them the spirit of Tech Talk Tuesday would cease to exist. So please start formulating your questions or comments and be sure to add the date to your calendar.

How to Attend
So be sure you click Add to Calendar in order to get the event details and a reminder on the day.

On the day of the event, join on Livestream or Facebook:

To submit questions:

And here are the full event details:

  • Tech Talk Tuesday: WebSockets
    Tuesday September 18
    9am PDT | 12pm EDT | 5pm BST
    Add to Calendar
September 12th, 2012

RESTful or Not?

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.

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!